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
... <snipped> ...
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.
---------- 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.
A link can be found by searching Google though and a notice at the top of the page states KB2687324 is replaced by KB2687627.We did not find any results for "KB2687324
TwoJ wrote:MS and the crack-head(s) doing the updates
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.
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!
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:-
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.
there are other concerns but this post is long enough.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
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
"New Setup.exe Fine Tunes Local Caching" for what it does new and why I need it.
Users browsing this forum: Yahoo [Bot] and 3 guests