Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


glnz

POSReady 2009 updates ported to Windows XP SP3 ENU

Recommended Posts

I was "archiving" all the POSReady stuff (documenting, saving all the tools used, etc), there are several options now to make new updated XP isos and using the new updates (of course people in this thread know what I'm talking about: POSReady=1, adding with nLite, adding to OnePiece Final pack, making a OnePiece AddOn, etc.). Thanks again for all your help.

 

Modifying the POSReady updates for XP is not really necessary anymore at the moment, but I still think it's a very clever idea, maybe we're going to need it again in the future. There's one thing that wasn't really clear to me though, I'll try to explain as clearly as I can:

 

- To save the "first part" of a localized update file, I did what I was told, and searched for the third occurence of the "MSCF" string. Then I deleted everything following that byte and saved the first part. For a Dutch update exe, this left me with a 44544 byte file.

- However, when I used copy /b to add this SFX module to the modified cab, it didn't work ("This is not a valid Windows program", or similar error).

- When I used a different update file (same version: 6.3.13.0) from a different KBxxxx update, things worked correctly. This one had the exact same filesize: 44544 bytes, both files were not 100% the same though, I believe the "padding" area was different. I don't have the exact difference available at the moment, but I could check if you want.

 

So my question is: How can I tell which one is supposed to work? Granted, this is not of the utmost importance at the moment (now that we have "POSReady=1"), but I was just wondering what I'm missing here. Thanks...

Share this post


Link to post
Share on other sites

As for the "functionality issues" argument in M$ statement this may be true only with a very limited set of files. For example, an update containing kblchecker.dll (KB2686509) had been released seperately for normal XP and Embedded versions. I can't give you a complete list of such files, however, it's worth find the differences between these 2 KB2686509 updates -  we might be able to make more general observations.

 

Embedded KB2686509 has kblCheckerE.dll but not kblChecker.dll

and it checks for HKLM\SYSTEM\CurrentControlSet\Control\ProductOptions\ProductSuite == "EmbeddedNT" as Prerequisite

Share this post


Link to post
Share on other sites

Please do take care!   :ph34r:
Messing with the ProductSuite has been reported to hose the system by Myrrh on this thread and this other thread, both at MDL.
 

[...] No luck duplicating on already existing machines, it will boot to a blank desktop image and just stick there. [...]

 

I was approaching it from trying to "change" the operating system to a different edition, with the difficult offline registry hack to the ProductSuite that crashed more often than it worked. The simpler one reported by theregister and other sources works good enough for now.

Share this post


Link to post
Share on other sites

I have read about one instance where a user performed the registry hack, downloaded what-ever updates were now being made available to his system, and upon a subsequent system restart got a "non Genuine Windows" notification or message.

Is it possible that one of those WGA "updates" was presented to his "POS2009" system, and it didn't like what it found and put his system into a WGA failure state? Even if he had previously either downloaded/installed the same WGA update - or perhaps there is a WGA update specifically for POS2009 systems?

I guess the take home message is, if you're using the POS2009 registry mod, you MUST select "Manual" mode when performing a WindowsUpdate session and look over every update being offered, and DE-SELECT anything related to WGA (and can anyone confirm or refute that any such WGA updates are actually being offered?)

Share this post


Link to post
Share on other sites

I wonder if the person who had the problem had messed with the "ProductSuite" registry entry.

As far as I'm concerned if Windows Update still offers and installs the new patches without changing that, I'm leaving well alone!

I have always manually scanned for and installed updates on Windows Update anyway, I've never let it do it automatically as I like to know exactly what's being offered before I allow it to be downloaded and installed.

It goes without saying that you must switch off the "Automatic Updates" option in the Control Panel too!

:)

Share this post


Link to post
Share on other sites

I guess the take home message is, if you're using the POS2009 registry mod, you MUST select "Manual" mode when performing a WindowsUpdate session and look over every update being offered, and DE-SELECT anything related to WGA (and can anyone confirm or refute that any such WGA updates are actually being offered?)

 

[...]  It goes without saying that you must switch off the "Automatic Updates" option in the Control Panel too!  :)

 

+1 Of course, using the "Manual" mode is the way to go. Even if not WGA, there's still many ways things can go wrong. However, I, for one, will henceforward make one full backup of the system partition, before adding any offerings each new patch Tuesday brings, and then, do it on "Manual" mode only, of course. But, for me, that represents no change, because that already was the way I always did it. Better safe (or, at least, as safe as possible) than sorry. :D

Share this post


Link to post
Share on other sites

Before installing the patches KB2926765, KB2931365 and KB2953522 is the ability of multiple adding and removing from the registry key [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]

After installing patches KB2926765, KB2931365 and KB2953522 removing of registry key [HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady] is absolutely impossible. Take ownership of key not have the effect. Does anyone know why (knows mechanism of the blockade)?

Share this post


Link to post
Share on other sites
Guest

U need to mount the hive offline to remove it. The mechanism is just a built in thing in Windows not unlike the driver signing thing I presume.

Share this post


Link to post
Share on other sites

Try to do it as the SYSTEM user (use PAExec, PsExec or RunAsSystem to run cmd and then run regedit, or use one of them to run regedit directly). It should be enough. If not, then do it offline, from Win PE.

  • Upvote 1

Share this post


Link to post
Share on other sites

Try to do it as the SYSTEM user (use PAExec, PsExec or RunAsSystem to run cmd and then run regedit, or use one of them to run regedit directly).

Unfortunately, no. I've tried this before (with the SYSTEM account) does not work.

If not, then do it offline, from Win PE.

U need to mount the hive offline to remove it. The mechanism is just a built in thing in Windows not unlike the driver signing thing I presume.

@egrabrych The reason is a kernel exception.

 

I have used this (PCRegedit):

PCRegedit.iso

It worked.

 

Thank you all :)

  • Upvote 1

Share this post


Link to post
Share on other sites

So what is the function of the WEPOS, WES and WindowsEmbedded\ProductVersion registry keys? Because there are reports that having just the PosReady key will work.

Share this post


Link to post
Share on other sites

Best I understand, effectively they are different versions of the same thing, but I also agree that just the PosReady key should be good enough for your needs.

 

Cheers and Regards

Share this post


Link to post
Share on other sites

So what is the function of the WEPOS, WES and WindowsEmbedded\ProductVersion registry keys?

Because there are reports that having just the PosReady key will work.

Of course, as reported by Sebijk in post #72, PosReady=1 is enough to get WU/MU working again and cause it to serve the POSReady 2009 updates, alright. However, when just that key is added, there appear some "Key Not Found" errors in the update logs, as reported by -X-, in post #76. So, harkaz found out which additional keys should be added, just to suppress those errors in the logs, and updated this thread's 1st post with that info, in .INF format. However, .INF format is less confortable, IMO, than .REG format, so that I added the same info, now converted to .REG format, to post #100, for it to be available for those who, like me, rather prefer to merge .REG files to the registry. Notice that both WES and WEPOS keys are set to 0. Just one of them ought to be set to 1, and POSReady is the best option. HTH.

  • Upvote 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   1 member

×