Office Integrator v2.0 requests thread


Slipstreams Office Servicepacks, hotfixes and custom HotPacks into your Office 2003 Suite. It also creates a reg file with needed entries to satisfy Microsoft Update.

Postby ChiefZeke » Fri Mar 01, 2013 1:47 pm

Was unaware TwoJ was creating the Ketarin download list - scratch that possibility.

AIO comment: If Office comes on 2 CDs then I would like to see OI have an option to merge the finished product such that the user can create one DVD and/or use one flash drive that can install everything.


I've heard of WSUS but have not tried using it. Today I downloaded WSUSOffline82.zip and extracted it.

I started it's Update generator and found Windows is limited to Server 2003, XP/Server 2003 x64, Vista/Server 2008, Win7/Server 2008 R2, and Win8/Server 2012. (My first read of the listing for XP indicates x64 - nothing about the 32bit version - assuming I did not miss something.)

The Office tab listed Office 2007, Office 2010 and a comment about Office 2013.

The Legacy products tab listed Windows XP (I'm assuming this is where you find the 32bit version) and Office 2003. (Comment here about end of XP in 2014.) This limits the Office selections. (Have no idea how many earlier versions are in use across the globe.)

The Options section appears to be the same when either the Windows or Office or Legacy tab is selected (seems a bit redundant).

In the Windows tab the options for Vista, Win7 and Win8 indicate Global multilingual updates - could be many unnecessary downloads here seeing as other options were language specific.

Overall, it looks fairly easy to use. I'm assuming that WSUS creates specific folders for whatever version of Windows and/or Office are selected and then creates specific folders for the downloads. FAQ was included - will have to read later for specifics.
ChiefZeke
Senior Member

Posts: 290
Users Information
Age: 75
Location: Victorville, California
Joined: Fri Mar 30, 2007 2:33 pm

Postby James » Tue Mar 12, 2013 3:09 am

Been watching this thread, but not had time to add my view until now...

I use the OI for Office 2003 & Office 2007 (up to and including the Pro/Enterprise versions of both).

benners wrote:
v1.2 of the OI has a problem with 7 digit KB numbers, it only retrieves 6 of them. I have sorted this and a few other things but with the release of updates that contain multiple msps i.e onenoteloc2010-kb2553290-fullfile-x86-glb.exe (76 msps) this causes a problem. As Office 2007 upwards are only copied to the updates folder there are some updates with the same name that are not superceeded by newer updates that contain files of the same name i.e outlook2010-kb2597090-fullfile-x64-glb.exe and outlookloc2010-kb2687623-fullfile-x64-glb.exe

outlook2010-kb2597090-fullfile-x64-glb.exe contains 1 msp (outlook-x-none.msp)
outlookloc2010-kb2687623-fullfile-x64-glb.exe contains 38 msps one of which is named outlook-x-none.msp so kb2597090 would be overwritten and required for MU to be happy. KB2687623 updates the files updated by KB2597090 but KB2597090 also contained 2 new files that don't need updating so technically KB2687623 doesn't replace KB2597090. Would be easier for me if every update was cumalative :mad:

... <snipped> ...



Actually Office .msp's ARE cumulative! Yes, really.

If you have two with the same name, (in this case outlook-x-none.msp) then the one with the latest date wins (that's the internal or digital signature date, NOT the date downloaded, obviously). If the the later one has a lower KB number that's just too bad -- it's not what governs the issue at all. So, in this case KB2597090 (released in Feb 2013) supersedes KB2687623 (released in Nov 2012). Trust me, I've been doing this for years and it works. I've also had it confirmed by Microsoft, but don't ask me where that email now is. KB numbers have never, ever, been a guide as to which is superseded by what -- in the case of the junk email updates they are all over the place as Microsoft seem to use-up "spare" KB numbers.

As to features, for v2.0, I always use the full slipstream for Office 2003 and the only real problem is, as others have already noted, the lack of support for 7-digit KB numbers.

The second problem, as I think I commented on these forums some months ago, is that Outlook updates don't always slipstream properly and MU then flags the update as needed, despite the fact that disassembling the CAB files shows that all the right files are present.

Using WSUS to determine the current update list is a nice idea, but the publicly available list, i.e. wsusscn2.cab, as used by the WSUS offline installer, has ONLY security updates in it. It has no other bugfix or feature updates in it at all. No, not one. That's not a problem for products no longer in mainstream support, like Office 2003, but it IS a problem for later products like Office 2010.

.[color="Silver"]

---------- Post added at 11:09 AM ---------- Previous post was at 11:02 AM ----------

[/color]Just to avoid any doubts, as to what i'm saying, I'm not saying that the entire KB is superseded if it contains different .msp files, just that if you have two .msp files coming from two different KBs with identical names for an individual .msp, then the later one wins.
James
Junior Member

Posts: 7
Users Information
Joined: Mon Mar 29, 2010 3:31 am

Postby benners » Wed Mar 13, 2013 5:59 am

James wrote:Been watching this thread, but not had time to add my view until now...

I use the OI for Office 2003 & Office 2007 (up to and including the Pro/Enterprise versions of both).



Actually Office .msp's ARE cumulative! Yes, really.

If you have two with the same name, (in this case outlook-x-none.msp) then the one with the latest date wins (that's the internal or digital signature date, NOT the date downloaded, obviously). If the the later one has a lower KB number that's just too bad -- it's not what governs the issue at all. So, in this case KB2597090 (released in Feb 2013) supersedes KB2687623 (released in Nov 2012). Trust me, I've been doing this for years and it works. I've also had it confirmed by Microsoft, but don't ask me where that email now is. KB numbers have never, ever, been a guide as to which is superseded by what -- in the case of the junk email updates they are all over the place as Microsoft seem to use-up "spare" KB numbers.

As to features, for v2.0, I always use the full slipstream for Office 2003 and the only real problem is, as others have already noted, the lack of support for 7-digit KB numbers.

The second problem, as I think I commented on these forums some months ago, is that Outlook updates don't always slipstream properly and MU then flags the update as needed, despite the fact that disassembling the CAB files shows that all the right files are present.

Using WSUS to determine the current update list is a nice idea, but the publicly available list, i.e. wsusscn2.cab, as used by the WSUS offline installer, has ONLY security updates in it. It has no other bugfix or feature updates in it at all. No, not one. That's not a problem for products no longer in mainstream support, like Office 2003, but it IS a problem for later products like Office 2010.

.[color="Silver"]

---------- Post added at 11:09 AM ---------- Previous post was at 11:02 AM ----------

[/color]Just to avoid any doubts, as to what i'm saying, I'm not saying that the entire KB is superseded if it contains different .msp files, just that if you have two .msp files coming from two different KBs with identical names for an individual .msp, then the later one wins.


Hi James, thanks for the reply.

You are correct with the information about the mps' modified (internal) time I was mistaken when saying that KB2597090 would be replaced. I was using OI v1.2 which sorts by exe modified time when adding but after extraction, it sorts the msp's by modified time. The new OI extracts the exes before adding to the list and using this KB2687623 is higher in the list (older) than KB2597090.

One check I will add is that if there are two exact named msp's from different KB numbers but one KB has multiple msp's then it will not be classed as obsolete. This should help reduce the errors when trying to identify obsolete updates.

I am still not convinced about the cumulative nature of the updates though. Either they are and MS needs to be more consistent with the update info on the web page or not all the updates are cumulative.

I have noticed this before when the Oi has classed one update as obsolete and TwoJ has informed me that it is still required by MU after an integration with the OI. One recent one I will attempt to explain is this:-

KB951535: Security Update for Microsoft Office 2003
When using both OI versions this was marked as obsolete and replaced by KB2687324. Using Microsoft Update Catalog (MUC) and searching for KB951535 found that until recently it was not listed as replacing other updates or as being replaced.

Extracting both exes found multiple MST files and a cab file. Extracting the cab file found only one file, this was
KB951535 - msxml5.dll.AB5E1073_AD9B_48DF_B07F_3E445B5A45CF
KB2687324 - msxml5.dll.AB5E1073_AD9B_48DF_B07F_3E445B5A45CF

The file gets renamed to msxml5.dll when integrating. So to me one replaces the other but searching for KB2687324 revealed that it wasn't classed as replacing any other updates.

Searching now shows that KB951535 is replaced by KB2760574 and KB2687324 returns
We did not find any results for "KB2687324
A link can be found by searching Google though and a notice at the top of the page states KB2687324 is replaced by KB2687627.

Extracting KB2687627 gives the same result as the two previous KBs, A file named msxml5.dll.AB5E1073_AD9B_48DF_B07F_3E445B5A45CF as does extracting KB2760574 . Searching MUC for KB2687627 says it doesn't replace an previous updates but this conflicts with the information on the support page (link above)

MUC says that KB2760574 replaces KB951535 and KB2687627 but no mention of KB2687324.

Phew, I hope this makes sense. I can add a check for same named msps, check the modified time and if names match and one time is newer then check if the newer update has multiple msps. If multiple msps then ignore and add as normal. If a patch is obsolete then don't process it. The problem is is MU reports it is needed then people will be posting that fact and really I need a way that works everytime :mad:

Cheers
benners

Posts: 502
Users Information
Joined: Sun Dec 31, 2006 10:40 am

Postby TwoJ » Thu Mar 14, 2013 8:34 pm

Well trying to stay on top of things by starting with the 2003 hotpack and right away - WTF
MS and the crack-head(s) doing the updates have decided to make the junk email filter from last november as a necessary update. Ok - not the first time and old junk email filter was replaced and then brought back (logic of this escapes me at the moment)! However now that its a required update again the hotfix is no longer available on MS Downloads!
So i can't provide a MS download link in the windows updater for that update - what i'm trying to work around is that i can get the msp - now i have to re-package it as an exe and then find a host where i can provide a direct url - i think i should have something for tomorrow. MS making me jump through hoops just to fill their ineptitude.

Benners - tell me, do you think its easy to add msp and cab to the accepted file formats accepted in the OI? Through wireshark i can get the URL of the actual download that MS uses to get the files which is not the same as MS downloads, Its essentially where WSUS gets their updates. So stuff like the email filter i have a link on the windowsupdate site that people can download direct through keterin but it downloads that file as a cab file.

For the renaming I've just being looking at the file details of the junk filter and in the name there is: Office 2003 Patch;outlfltr;11403;FullFile;ALL
for KB2687403 and KB2768025 gives :Office 2003 Patch;outlfltr;11411;FullFile;ALL
so there is that number 11403 (older) & 11411 (newer), I'n not sure if that is a revision # or what, don't know if it exists on all files, I checked the two Outlook.msp that are issues (KB2449798 & KB980373) and they both have revision #s. So if that number is consistant you might consider 'OUTLFLTR_11403.msp' and 'OUTLFLTR_11411.msp' which should list them in order for 2007+, or alternatively to extract the creation date and do it with that ie 'OUTLFLTR_20121015.msp'. If it could be confirmed that the revision # is a consistant throughout MS crappy update system i think thats cleaner that the date system, however as you know MS ALWAYS seems to release at least one update that breaks the scheme so i think the date might be more MS standard proof!

anyways time for some get-away from the computer after 16hours its enough - I'll continue hacking at it tomorrow!
TwoJ
Senior Member

Posts: 465
Users Information
Joined: Fri Apr 06, 2007 1:09 pm

Postby benners » Fri Mar 15, 2013 4:03 am

TwoJ wrote:MS and the crack-head(s) doing the updates

Agreed ;)

TwoJ wrote:Benners - tell me, do you think its easy to add msp and cab to the accepted file formats accepted in the OI? Through wireshark i can get the URL of the actual download that MS uses to get the files which is not the same as MS downloads, Its essentially where WSUS gets their updates. So stuff like the email filter i have a link on the windowsupdate site that people can download direct through keterin but it downloads that file as a cab file.

Its not too hard, as with probably most programs its the error checking that adds up. If the file is office2003-KB2687403-FullFile-ENU.exe I have a copy I can send.

TwoJ wrote:For the renaming I've just being looking at the file details of the junk filter and in the name there is: Office 2003 Patch;outlfltr;11403;FullFile;ALL
for KB2687403 and KB2768025 gives :Office 2003 Patch;outlfltr;11411;FullFile;ALL
so there is that number 11403 (older) & 11411 (newer), I'n not sure if that is a revision # or what, don't know if it exists on all files, I checked the two Outlook.msp that are issues (KB2449798 & KB980373) and they both have revision #s. So if that number is consistant you might consider 'OUTLFLTR_11403.msp' and 'OUTLFLTR_11411.msp' which should list them in order for 2007+, or alternatively to extract the creation date and do it with that ie 'OUTLFLTR_20121015.msp'. If it could be confirmed that the revision # is a consistant throughout MS crappy update system i think thats cleaner that the date system, however as you know MS ALWAYS seems to release at least one update that breaks the scheme so i think the date might be more MS standard proof!

The number you mentioned is from the MsiPatchSequence table. If there are updates from the same family, i.e outlfltr, then the updates are sorted by sequence number and installed in that order, and, something I can't suss, it is also used with other aspects to determine supercedence. It is present on other updates and that will be the new renaming method. I think I mentioned it earlier in this thread as there were to other surefire solutions.

Cheers TwoJ
benners

Posts: 502
Users Information
Joined: Sun Dec 31, 2006 10:40 am

Postby James » Sun Mar 24, 2013 9:34 am

benners wrote:
I am still not convinced about the cumulative nature of the updates though. Either they are and MS needs to be more consistent with the update info on the web page or not all the updates are cumulative.

I have noticed this before when the Oi has classed one update as obsolete and TwoJ has informed me that it is still required by MU after an integration with the OI. One recent one I will attempt to explain is this:-

... <snipped>



You've certainly focussed on the core problem there. In my view Microsoft is most inconsistent on the update info that it publishes on its web pages, especially on the info it provides as to which updates supersede which and also for the converse as to which updates are superseded by which. I get the impression from others who regularly deal with patching that they think the same way too. The info is at its best when dealing with Security updates (as published in the Security Bulletin on technet) and at its worst when dealing with Hotfixes in the narrow sense, which are the available fixes that are available only on request (usually by email or maybe only from MSFT PSS) and do not appear at the Download Center or on MU. There are literally hundreds of non-Security fixes where the publicly available supersedence info is either not given at all or just plain wrong.

For the XML 5 patch that you give as an example, yes I can certainly follow what you are saying, but it happens to be a particularly messy example because this was affected by the complete pigs-ear that MSFT made of digitally signing patches last summer.

The original patch in this chain is KB951535 a.k.a MS08-069, issued in November 2008.
In August 2012 it was replaced by KB2687324/MS12-043. That patch was one that was part of the digital signing fiasco.
In November 2012 KB2687324 was replaced by KB2687627. Exactly the same patch, but this time correctly signed.
At the same time KB2687324 was withdrawn. It was expired and removed from the update servers. It can no longer be downloaded.

Now, incidentally, KB2687627 is also obsolete. It was superseded last month by KB2760574/MS13-002.

TwoJ, probably knows all this just as well as I do, since in his Hotpack for Office 2003 only the MSXML5.msp from the latest KB2760574/MS13-002 is included.

The problem remains as to what to do when MSFT update info is just plain wrong. The current example of that (keeping with Office 2003) is with the Junk Email filter for which the actual patch is OUTLFLTR.msp. If you just integrate, or slipstream only the latest version (KB2768025) MU will complain that an earlier patch is still missing. The missing version is KB2687403 from August 2012. If you operate your own network update server (i.e. a "proper" WSUS server installation) this can also clearly be seen in the WSUS Console where KB2687403 still appears in the listing, although later versions have been expired and removed. Scrolling down in the WSUS Console lower pane to the superseding/superseded info pretty much confirms to me that MSFT have broken the chain of which supersedes what.

When MSFT info is wrong, it's going to be pretty hard to have an OI that works 100% -- all of the time. For the Junk Email filter problem, there are only two workable solutions:
(1) As TwoJ has done, just include both patches, but rename one of them to avoid the name conflict;
or
(2) Patch the Registry (at HKLM\Windows\Installer\....) to fake the installation of the earlier patch. I have seen this done in the German list for integrating Office 2003 (the list by Nemo).

Maybe there should be a way for OI to incorporate custom Registry entries in the integration? That's in addition to the .REG file it already makes, of course.

Could that be done easily, or not?


PS: Completely OT: It's difficult to post long replies, like the above, because the forums are timing-out my login.
.
James
Junior Member

Posts: 7
Users Information
Joined: Mon Mar 29, 2010 3:31 am

Postby benners » Sun Mar 24, 2013 11:58 am

James wrote:The original patch in this chain is KB951535 a.k.a MS08-069, issued in November 2008.
In August 2012 it was replaced by KB2687324/MS12-043. That patch was one that was part of the digital signing fiasco.
In November 2012 KB2687324 was replaced by KB2687627. Exactly the same patch, but this time correctly signed.
At the same time KB2687324 was withdrawn. It was expired and removed from the update servers. It can no longer be downloaded.

Now, incidentally, KB2687627 is also obsolete. It was superseded last month by KB2760574/MS13-002.


Thanks for the info it explains things I have noticed when checking patches. It's about time MS and its employees upped there game :D

W.R.T to the integration part. I had thought to add dummy entries when integrating, this would correct any problems with incorrect info on MU. I decided against this as without extensive checking I could never be certain if the update was truly required. If it was it would leave folks installations unpatched and perhaps vunerable, so I shelved the idea.

The one I am currently using is the renaming option. When adding updates to the list, they are all now extracted, this is more flexible in obtaining required info and I have more control over what files go where. When added to the list there are a few checks carried out.

  1. The list is scanned from the first update for identical Patch GUIDs. If found they are unchecked as are all other updates with the same KB number.
  2. If there is an exception in the OI.ini for the KB number, remaining checks are skipped. The OI entry is a way to mark an update as required if the OI thinks it is superseded.
  3. The current update is checked for identical file names. If found, further checks are carried out unless the update has been unchecked through previous checks.
    [INDENT]
    • Platform check (x86/x64) - if they difer, skipped, if identical then next check.
    • language check - if they differ, skipped, If identical then next check
    • MSP count (Number of patches in the update) - If the count differs, skipped, if identical next check.
    • Patch Sequence - If the updates have a higher sequence and if Office 2007 upwards it will be deemed as superseded. With OfficeXP and 2003, same scenario but patch codes checked for information
    [/INDENT]
  4. If the previous checks don't provide a match and If Office 2007+, next update is checked. If OfficeXP/2003 then the patch codes are checked to see if the current patches code appears in the ones classed as superseded. I have noticed one update KB905649 - OLKINTLff.msp, replaced by KB2293422 - OLKINTL.msp, different file names.

    This is not ideal really as according to MS
    If there is sequencing information present in the MsiPatchSequence table, Windows Installer 3.0 uses the sequencing information in the table and ignores the list of superseded patches
    there are other concerns but this post is long enough.

  5. Finally, if an Office source is selected on the integrate tab, the updates are checked against it to see if the updates are valid for the product.


I sympathize about the timeouts, I can't alter those settings, it requires access to the Admin Control Panel and I only have access to the Mods CP. This is probably a good thing as I can only do so much damage.

Siginet has mentioned the site is due an overhaul in the future. Until then, I just keep previewing the post to keep the connection active :D
benners

Posts: 502
Users Information
Joined: Sun Dec 31, 2006 10:40 am

Postby James » Thu Mar 28, 2013 2:53 pm

There is one issue with OI that I forgot to mention.

I was looking at my notes of my last Office 2003 slipstream and I see that the OI completely fails if the original Setup.exe (dated 2003) is replaced with the later released version (version 11.0.6176.0, dated 2004). I need the later Setup.exe version for deploying with the ENFORCECACHE property set. If the later version is in the source folder then the OI just crashes or does nothing. What I have had to do so far is run OI then manually replace each instance of Setup.exe in the DEST folders before burning to a new distribution CD.

See "Office 2003 Update: Enterprise Release of Office 2003 Setup.exe" for the download

and

"New Setup.exe Fine Tunes Local Caching" for what it does new and why I need it.

.
James
Junior Member

Posts: 7
Users Information
Joined: Mon Mar 29, 2010 3:31 am

Postby benners » Fri Mar 29, 2013 8:59 am

James wrote:There is one issue with OI that I forgot to mention.

I was looking at my notes of my last Office 2003 slipstream and I see that the OI completely fails if the original Setup.exe (dated 2003) is replaced with the later released version (version 11.0.6176.0, dated 2004). I need the later Setup.exe version for deploying with the ENFORCECACHE property set. If the later version is in the source folder then the OI just crashes or does nothing. What I have had to do so far is run OI then manually replace each instance of Setup.exe in the DEST folders before burning to a new distribution CD.

See "Office 2003 Update: Enterprise Release of Office 2003 Setup.exe" for the download

and

"New Setup.exe Fine Tunes Local Caching" for what it does new and why I need it.

.


That's partly because of the sort2cabs.js that is run during the Direct Integration. It checks the setup.exe against the one in the cabinet and as it differs it errors and the process isn't fully complete.

It is easier to just copy the exe over after integration, replacing the old one, otherwise you have to replace all three setup.exes, update the msi with the new file size and version and replace the setup.exe in the cabinet file as well. This should produce an error free integration.
benners

Posts: 502
Users Information
Joined: Sun Dec 31, 2006 10:40 am

Postby TwoJ » Tue Jun 18, 2013 12:41 pm

Hey Benners

I think after 20 plus installations of Office 2013 I think I found an issue - with the hotfix rename to KBxxxxxxx_Hotfix-name.msp it seems with one of the new hotfix, KB2767865 and KB2810019 it seems that the installation gives an error because it can't handle a capital letter at the beginning of the hotfix (ie K....). If I rename it to lowercase kb2767865_hotfix.msp it works fine, also numbers at the beginning seem fine (ie 2KB..) but any combination of a capital letter at the beginning (ie Z2767865.msp) will cause it to have an error in installation.
Thought I would share this as it has taken some time to track this down, not sure either why I haven't experienced this before, or maybe somehow its new to the integration?
Anyways not sure if you have settled on a way to rename hotfixes with the same named msp within them but whatever it is make sure it doesn't capitalize the first character if its a letter. Of couse whatever you choose i'm sure Microsoft will find an exception to it!
TwoJ
Senior Member

Posts: 465
Users Information
Joined: Fri Apr 06, 2007 1:09 pm

PreviousNext

Return to Office Integrator

Who is online

Users browsing this forum: Yahoo [Bot] and 3 guests

cron