7 replies to this topic

[older-than-dirt]

First of all, I want to say thanks for AP. I have been using is for several years (?) now - since the "old" way of packaging everything and the current way. I have a question:

I use AP to patch lots of virtual machines running various flavors of XP (SP2, SP3) that are used to test a product in. We have one customer that will never move to XP SP3 because the have a 3rd party lib that is not compatible (it's a long story). Instead they are moving directly to Windows 7 (skipping Vista). But until that happens they have to test our product along with theirs in an XP SP2 environment.

When MS releases patches they specify which service pack(s) it applies to. Currently AP for XP supports and gets patches for SP3. (some of which may or may not be applicable to SP2)

So the question is: Is there any way to configure or setup AP so that it only gets (and applies) patches that affect XP SP2? In effect creating a "version" for XP SP2?

Thanks.

[James]

This can be done in exactly the same way that every other AutoPatcher release is done -- by writing a complete script and set of modules (APM files) for XP SP2.

==

[older-than-dirt]

ok.

So a couple of more questions:
- Is there documentation that I can read on how to do this?
- Is the last script for SP2 still available so that I don't have to start completely from scratch?

Thanks.

[Cristiano]

yes, there's some sort of documentation about build modules and the script. it's lacking some info, but it shall do. you can download that documentation from here

about the last sp2, we have an backup for that one, but now, it's pure garbage. not because all links are dead, but due the time without any update. from times to times, an update replaces another one, that is replaced by another one, etc. even if half of those links aren't dead yet, you may bet that half of them was already replaced and, due that, your task will be far worst than build one from scratch, just taking wu as a template. also an guess, i would say to you take the documentation about sp3, see what updates that one was replacing and then add the post sp3 updates. but the sad part is that sp3 was just an bunch of updates and, due that, you never will know with update will do the incompatibility issue that your client has found and, for sure, one of them will do the same, even if you don't update to sp3

[]s

[older-than-dirt]

Cristiano, on 23 August 2009 - 04:28 PM, said:

about the last sp2, we have an backup for that one, but now, it's pure garbage. not because all links are dead, but due the time without any update. from times to times, an update replaces another one, that is replaced by another one, etc. even if half of those links aren't dead yet, you may bet that half of them was already replaced and, due that, your task will be far worst than build one from scratch, just taking wu as a template. also an guess, i would say to you take the documentation about sp3, see what updates that one was replacing and then add the post sp3 updates. but the sad part is that sp3 was just an bunch of updates and, due that, you never will know with update will do the incompatibility issue that your client has found and, for sure, one of them will do the same, even if you don't update to sp3

[]s

So that I understand.

1) Do a fresh install XP SP2
2) Turn on Windows updates, let it run
3) After it's patched, get all of the patch info from the machine
4) Create AP scripts that get the same patches
5) Apply SP3
6) Allow the Windows updates to run again
7) Get the list of new updates applied
8) Go through the list of updates and see which also apply to SP2
9) Add these to the AP script(s)
10) Test, test and more testing...

Does Windows updates remove old patches that are superceded by newer ones - or is the "big" problem in that this all has to be done by "hand" because of obsoleted patches that are never removed by WU, but AP can/is scripted to remove obsoleted ones?

I downloaded the docs, I will read through them over the next week or so. Or maybe I just live with this mess until the customer moves to Win7

[Cristiano]

well, the main problem is that your client issue is created by one update that is included in sp3. so, the only one problem that i know to pinpoint issues like that is one by one (and yes, this will not be easy).

> obsoleted patches that are never removed by WU
wu or even the patches installed "by hand" don't remove the old ones. in fact, they do backups in order to allow you remove them and restore the previews update

> 5) Apply SP3
well, sp3 can be applied straight over sp2. if the idea is apply sp3, then there's no need for any update between sp2 and sp3. but if the idea is avoid the update covered by sp3, then you will have to manually download the updates covered by sp3, apply one, reboot, test, apply another one, reboot, test. or, in order to make it more easy, in groups. the problem will be if you try it in groups, when you find the issue, you will have to do everything again and test one by one of that group. an idea: in certain vms, you can set the vm to restore to his original state. it may save you some time...

as for seven, your client issue just happen with xp sp3 and vista? seven has an vm of xp, but a lot of things will not work under that. worst: to run vms, you will require seven ultimate. but with xp, you only can't run a vm from that (blarght) starter edition.

[]s

[LostUser]

Maybe I am not getting something, but why install xpsp3 if you are looking for updates to xpsp2?

Can't you just install xpsp2, install all the updates, then keep running WU to get the latest updates for xpsp2? I haven't updated one of my PCs to xpsp3 and it still gets WU for sp2. Then, all I have to do check the KB# and download them as unexpanded installs.

Also, you can subscribe to windows updates alerts via email, then check those alerts if you want to take the time for that.

[Cristiano]

> why install xpsp3 if you are looking for updates to xpsp2?
because we don't do any script for sp2 nor we test the scripts with sp2 and because our rules about scripts are clear: we just do scripts for the current service pack for any OS. since the current service pack for windows xp is sp3, we don't give any kind of support to service packs prior to sp3.

[]s