Windows xp sp2 workaround

This will open the "Run" program from which you can access your PC's registry. Doing so will launch the Registry Editor tool. Review the options tree on the left side of your screen. You'll need to navigate through several of the folders listed here in order to reach your destination. Since the registry holds most of your computer's sensitive system information, consider clicking File and then Export in the top left corner of your screen to back up your registry before proceeding.

Click the "WPA Events" folder. Don't expand this one. You should see its contents listed in a window on the right side of the Registry Editor page. Click Modify. These should be several pairs and sequences of random numbers. Tap Delete. This should remove the values listed here. Type in new numbers. It doesn't matter what you put here, but you'll need to keep the format consistent for example, if you deleted four characters, you'll need to replace that section with four characters.

Click OK once you're done. This will save your changes. Open the Run tool again. Exclude the quotation marks. Entering this command opens the Windows XP activation wizard. For best results, simply copy and paste this text into the Run field. Click OK. Select the telephone option. This option should say "Yes, I want to telephone a customer service representative to activate Windows" and there should be a clickable check box to the left of it.

If you see a note that says "Windows XP is already activated", changing your key manually isn't working. Please proceed to the Windows Key Finder method. Click Next. Click Change Product Key. This is at the bottom of the "Activate" window.

Enter a Windows XP product key. Note that you may have to attempt this step a few times with different keys. If you don't know the version of Windows XP your computer is currently running, consult your computer's manual to verify before you proceed with trying the linked product keys.

Click Update. After this process completes, you'll need to confirm your activation of Windows XP. Click Back. Check the "Activate Windows over the Internet" option. This will allow you to activate your version of XP quickly. Note that calling Microsoft using the "telephone a customer representative" option likely won't work since Microsoft discontinued support for Windows XP on April 8th, Follow the on-screen instructions.

After you've completed your Windows XP activation, you should be able to use it without getting locked out of the system. Method 2. Open the Winkey Finder website. Winkey Finder is a free, no-install program that can locate and retrieve your Windows XP product key. Click on the latest version of Winkey Finder. As of January , this is version 2. Since this version is currently in beta, you can also download the final version of 1. Click Download Winkey Finder.

You should see this button at the bottom of the Winkey version page. Right-click the Winkey folder. It should be wherever you chose to save it when you clicked Download e.

Application errors in 'comctl Some random ArcGIS 9. In these rare cases, repairing the system files solved the issues. One of the following scenarios will occur when an AML script is run: An empty DOS window appears but nothing happens and the script does not run. The progress dialog box indicates that the script is running but nothing happens and the script does not run. In the line below, replace arc. When the changes above are made, double-click the file. When asked if you want to add the information to the registry, click OK.

When informed the information was successfully added, click OK. To correct this, add exceptions in the Windows Firewall. Workaround - For more information on this issue refer to the following Esri Knowledge Base article: Bug: XML declaration may only appear at the beginning of the document.

In general, database vendors do not regard Windows XP as an operating system for production databases. For that reason, we do not test or otherwise certify the ArcSDE 9. Since you have a double-negative mixed with a positive, so the literal definitions of your statement is that it is absolutely going to change, I suppose you can opt out of this argument. But I assume you meant, "It's never, ever, going to change. But I agree with the literal meaning: it is absolutely going to change.

In fact, I will bet my retirement fund that it changes before 25 years pass. In fact, I will bet that dynamic installers won't exist as we know them today. If Microsoft fixes this by adding an option for "can" or "available" updates, or by changing the behavior of dynamic installers in WSUS, it won't be the first or the last time that Microsoft does something and then reverses claiming the fix was some brilliant new way to do things.

Things change, things evolve. The fact is, when Microsoft decided to use their updatw system to distribute not only updates but also new products, they went again the original purpose of the software itself, intriducing a not perfectly fitting feature: deployment of additional software.

When WSUS told us an update was needed, it meant "you NEED to install this update to fix something", an objective statement: Lawrence is wrong when he says that is human's decision to rule if an update is needed because the concept of need is subjective.

The human decision is, instead, to not install the update and leave the security hole, but the update remains to be needed to its purpose.

Now, with new product deployment through WSUS, the question it should ask us would be: "would you like to install this new product? Windows Update has an "optional" can't remember the correct name section right? I was having issues with WSUS and ran across this. Total waste of time reading this.

Maybe those tools aren't intentional. Simple approval of what's needed by client machines, reports of computers needing these but not yet installed problems , and optional separate components available. I'll approve manually the optional ones. Not coming back here but just wanted to let everyone know what I feel are how most administrators are using WSUS, whether incorrectly per Microsoft or not.

It's a tool many administrators need. I'll check back just to see if there's such a replacement tool for WSUS that does exactly what I expected.

Anybody who is applying this philosphy to their patch management methodology needs to seriously reconsider that choice. Interpreting a pie chart legend label as Gospel Truth without actually researching the design or intent of the product or display , is a fast track to this very problem. FWIW, most of the organizations I have seen that opted for 1 later regretted that decision.

The expense, and negative impact, were simply too much in the end -- but generally not recoverable, and additional expense and negative impact were encountered to "undo" that initial bad decision. These decision were almost always a result of perpetuating defective processes and practices in the first place, rather than recognizing that the reason the product did it a certain way is because that is how MOST healthy processes actually work -- and maybe the organization needed to re-evaluate how they were doing certain processes and practices.

Patch Management is not a new discipline, and there's twenty years of experience and practices that pre-dates Microsoft's first release of an update to Windows Update merely a dozen years ago. WSUS is a tool. It provides information. Interpreting that information correctly is the responsibility of the IT Professional assigned to use that tool. An update is NEEDED to fix, add, remove or change iny way some piece of software, and it stays that way either if the administrator applies it or not.

In case of a security patch, for example, an Administrator could decide to not apply it because some other factors mitigate the risk addressed by the patch in his enviroment a firewall, for example. So what's not in the client, could and actually is defined in the server software. Nice words.. What in the does a new install to do with deploying patches??? And, infact, this kind of packages in WSUS are relatively new. The original purpose of the product was just to deploy updates.

I agree with you to adapt my practices and philosophies to the product I use, but I cannot change it every time the producer decides to change is mind.

I saw something you posted a couple of years ago see below that indicated the application might not be converted to a role. Would that be a problem or just different? Even if you could, I'm not sure how you would convert it from an application installation to a role. The only reason this problem comes about in the first place is because WSUS admins are selecting Product Categories that they obviously do not need!

As noted in the quote you cited -- I had not personally done that, so the answer was speculative, and I stated so in my response. I do not state things in my posts as factual unless I have personally observed it to actually occur, or there is factual information to support such a statement.

Sufficient empirical evidence exists today from thousands of other installations on disconnected servers to confirm that this is a non-issue. So trying to catch up here. I did read through all posts and while entertaining I'm still trying to get a solution for the percenters, as I am one of them also. The solution to this may not be as bad as it seems. The understanding of what a Dynamic Installer is and what you would miss without having them delivered through WSUS may be the entire problem.

By choosing not to have Dynamic Installers delivered through WSUS would not mean that I would miss out on updates to the products themselves, but just updates to install them through the Roles and Features of Server Manager? You don't even lose the ability to install them, merely to install them using a LOCAL source for the installation bits.

In fact, that is the exact purpose of having published the Dynamic Installers to WSUS -- so that client systems do not need to individiually download the bits via the Internet to do the installation -- they can get them locally. So that sounds like a perfectly fine solution.

You will still get your pataches and updates for the WSUS product. It seems you will also have to decline this particular update since this update will remain even after you have excluded the above product. I have always enabled all patches regardless of the "Does this server need it or not" consideration that the current moderator seems to love.

I never had any problem with this and never will waste any time on choosing which update I need to apply or not on a server. WSUS is a patch deployment server and we don't need to know which patch needs to be installed or not We need to update everything that can be updated or installed on the server. I'll decline this update but it's the first time I need to decline an update to be happy and see all my servers being green.

I hope but they usually don't listen a lot to us network managers. Also, dear Moderator, I find your answers very unnecessarily aggressive Everybody has their own opinions and methodologies, but it needs to be noted that this philosphy contravenes every "best practice" about patch mangement that has existed for the past 40 years. The purpose of this forum -- one of the purposes of this forum -- is to discuss the right way to do patch management with WSUS.

As frustrating as it may be, sometimes that's not the same thing as the easiest way. New products shouldn't be deployed by Microsoft I mean with that. It contravenes the simple meaning of "patch management system". But, as I already said in other posts, not everyone have the time and the resources to really test the patches against their specific software setup.

The amletic choice is to update and eventually deal with problems or to not update and deal with vulnerable systems.

I'm usually going with the second one, and Im not having troubles since a long time ago. WSUS is good for me at least as "download caching" and reporting tool. Some times ago, however, following your suggestion I excluded some categories from autoapproval and did not have anymore the dynamic updates problem.

In a logical usage, it would only be deployed to computers or servers that have Silverlight installed and not take the initiative to install it Also, if you have time to test every patch MS is publishing In the real life, here's how it works : my department is only made of 4 persons and we are in charge of 15 foreign offices from Japan to the US including South America and Asia and 6 different sites in France.

We really don't have time to deal with patch testing. Again, in the real life, when you have a problem and call a publisher, they all ask you if you updated your computer with the latests patches According to me, not updating is out of a question. I would rather deal with crashes than with security holes.

I also don't have patches that are not installed I don't want to learn how to use Dynamic Installers because I don't understand the point in this So what is it used for? I'm sorry Lawrence Garvin from Texas, but after reading this thread, your input into answering the question has been absolute trash.

You may aswell have not replied to any posts here as you really have not helped anyone. I have wasted my time reading your useless replies which have annoyed me so muchthat I have taken a moment out of my ever so busy schedule to write this. I don't disagree with you, but the status option are what they are.

Thus, a more simple solution is to simply accept that some systems are going to report some updates as "Needed" and that's just the way it's gonna be because those updates are not going to be installed on those systems.

It's a legitimate request but, in reality, it's not going to happen. WSUS is a "feature complete" product, and has been for over five years. It's in "maintenance mode". And unless something earth-shattering happens in the patch management discipline or the Microsoft Update infrastructure, there are not likely to be any more feature enhancements to WSUS. Yes, it has always annoyed me that the WSUS developers chose to consolidate those three actual states NotInstalled, Downloaded, InstalledPendingReboot into this pseudo-state of "Needed", which has caused many more headaches and heartaches than was necessary.

The irony here is that this is how WSUS v2 actually operated. Otherwise, an update that was not set to "Detect Only" or "Approved" was always reported as "Not Applicable". There's a whole horde of discussions that went on in in the WSUS newsgroup about this change and you may be able to find thim in a Google Groups search , and initially I didn't agree with the decision either -- but after many months of discussion, I came around.

The primary benefit of setting all updates inherently to "Detect Only" in WSUS v3 was that it prevented Security Updates from being accidentally missed in the scans. You and I, however, represent a very small microcosm of the WSUS community that recognizes the value of this package for installing replica servers, and so, being in the minority, we get the joy of "sucking it up".

I have Win systems flagged by this update also. I've just learned to ignore that data as I have the Silverlight 5. That's an excellent approach! Thus, there are no bits from the installation media to pre-cache in the WinSxS folder. Garvin The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

The update is reported as "NotInstalled" because that's a factual statement. The purpose of a Dynamic Installer is to do it when requested by the system where it is to be installed. This is not an "install on every WinR2" system type of update.

The bits are downloaded from the local WSUS server. A replica server can be installed from a local instance of the bits stored on the upstream WSUS server, rather than having to be downloaded from Microsoft across the Internet every time the server needs to be installed. So an admin is supposed to know that it's normal and "expected" that servers show up as a "yellow warning" status on the WSUS dashboard simply because they might someday in the future install a role that is not yet installed? This is not new stuff; it's been the case for servers since the release of Windows Server over 13 years ago, long before the creation of WSUS!

There needs to be another state, other than needed, because that implies that the update is ready and the server is either ready to install it because it was recently approved or is failing to detect it. Your design thoughts are noted, but you're barking up the wrong tree.

That "feature" was built into the original version of WSUS v2 in and had catastrophic results. It was removed from v3, in , because of those catastrophic results. The problem here is the dichotomy between expecting a product to operate the way you want it to operate, and understanding the way a product actually operates and adjusting accordingly.. Yes, I'm sympathetic to the fact that things are not the way you want them But relay the topic is about " Needed" and the KB isn't!

And, as I've written elsewhere in this thread several times If you continue to interpret the word "Needed" in the way you want to, you'll continue to be confused by the state of things. The only change that needs to be made here is how you choose to interpret the term "Needed".

There's your second misunderstanding. Perhaps you should take a look at that Silverlight package. Either you've declined it for ALL systems in which case your Silverlight v5 installations currently have a critical security vulnerability, or you declined it after installing it to the systems you wanted to ,. It doesn't change how the update is reported; only changes the fact that the system won't install the update.

Unless you fail to understand the purposes and distinctions of: Approved NotApproved Declined. You might consider that your only choice. I don't. The question remains one of whether people get all bent out of shape because the display shows what is factual, rather than what they WANT it to display. Approve Silverlight for Desktops.

Don't approve it for Servers. Valid compliance data for Silverlight as relates to only Desktop systems. Who cares what's displayed in the console!? It's all simply a matter of knowing the proper way to use the product, which requires one to accept the quirks, particularly those you may not like, and work within those constraints. I'm sure there are MANY software products in your environment that don't work exactly like you wish they did. You can either invest your energies in complaining about how they work, and get no real work accomplished, or you can work with how they work and get the work done and still be home for dinner at the end of each day.

All in all it's nothing but a matter of personal choice where one chooses to invest their energies. I've got lots of things I'd rather be doing than whine because some piece of FREE software isn't exactly to my liking.

Office Office Exchange Server. Not an IT pro? Windows Server TechCenter. Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. Asked by:. Archived Forums. Sign in to vote. See the Microsoft Discussion Forum public. Wednesday, September 2, PM. None of these servers have any WSUS components installed.

I understand that the Dynamic Installer update will update the installation files on the systems so that if you decide to install WSUS later down the road, it will be SP2.

Not sure why the servers are not installing it. I remember this update coming out for SP1, and the servers did install that fine. Thursday, September 10, PM.

Dynamic Installer packages do NOT behave like conventional update packages do. You understand this incorrectly. I have not tested what happens if the package is Not Approved and an existing WSUS Server is already assigned, but my gut tells me the installation will fail and report it cannot find the needed content.

They are one-and-the-same activity. There is no "pre-staging" of the WSUS installation files, as it seems might be your understanding. Friday, September 11, PM. I appreciate that the behavior is "unexpected" -- things change, things evolve, and we all have to be willing to adapt to NEW behaviors of the systems and technologies we use. NET Framework v3. Saturday, September 12, AM. This would allow us to easily check if all our approved updates got installed, which is essentially what we want to achieve here.

Cheers Michel. Tuesday, September 15, PM. Cheers Michel I agree I think this would a welcome addition. But would be cool to have it as a column, too. Would be easier instead of generating reports. Then do it the way we've been doing it for the past four years.. Wednesday, October 28, PM. Bagnoli This is not true. This is "Works as designed". Try googling for it, and you will find an official statement from Microsoft. Thursday, October 29, AM. It works only with Windows XP. Be very careful when you download it.

If you choose to download the file, make sure you scan it with an updated virus-scanning program before using it. The file itself, Viewkeyxp.

There is no installation program. Just run the program, either from the command line or by double-clicking it from the folder you downloaded it to.