cluberti

Well, we generally frown on warez copies, but XP Professional comes in these basic "versions": 1. Volume License (sometimes referred to as "corporate" versions) - these versions use VLK keys and do not require activation 2. "Retail" OEM - these versions can be purchased in stores, use specific OEM keys not tied to hardware, and must be purchased with (computer) hardware, and also must come preinstalled by a system builder or an OEM (even if that's you). 3. "Royalty" OEM - these versions come only from big-box OEM vendors, preinstalled on a computer, and have specific keys tied to that vendor (and in some cases the system's BIOS) 4. Retail - this is the fully-packaged product you can get in a Windows XP box from a retail store. If you're looking to keep your OS updated, consider looking into nLite or HFSLIP.

No, posts to microsoft.com for SP3 are OK, as are posts about SP3 elsewhere. Just no torrents, or softpedia links, etc.

We use WDS (Windows Deployment Services) running on a few Server 2008 boxes to deploy Vista WIM images from a PXE boot. These are not prebuilt in any way, they are straight WIM files from installation media (Vista Enterprise) that auto-register with the KMS servers, and SMS is used to install any software post-build and scripts for configuration. During our migration, we were phasing out XP, so we made WIM images out of our current XP images (they aren't changing anymore), so we do once in a while deploy an XP box from WDS, but it's rare (it works, just rare for us to do nowadays). Servers are built on a separate, self-contained network before they hit production, so we are still using 2003 Server running WDS in Mixed mode (so we can deploy 2003 RIS images and 2008 WIM images from the same servers). However, these are still straight installs, not sysprep'ed, using SMS to do an post-build software installation and scripts for configuration.

Windows XP x86 is built from the Windows XP x86 OS tree, and is serviced up to Service Pack 3 currently. Windows XP x64, while keeping the "XP" name, is really built from the Windows Server 2003 tree and as such is serviced with Server 2003, not XP. Server 2003 is at Service Pack 2, so XP x64 is at Service Pack 2 as well. When Server 2003 gets a Service Pack 3, XP x64 will get the same service pack. Even though they're both called "Windows XP", they are not built from the same OS build tree, and as such will have different service packs that are not compatible with each other (you can't install XP x86 SP3 on XP x64, and you cannot install XP x64 SP2 on XP x86, for example).

In the \i386 folder, look for "SPx.cat" - if you have one, then you have SP x slipstreamed (whatever X is, that's the service pack level). If you've got no SPx.cat file, you have an RTM source.

And as good as the DEC was, it was still 32bit on a 64bit processor (boo) . But yes, SPARC was an OEM release, mostly Integraph as the vendor. Also note that even if you do manage to get your hands on a SPARC version of NT4, there won't be any easily available service packs and updates (those were only released for the DEC and x86 - for all other architectures, it was up to the OEM to port and recompile, from what I remember. However, a good debian sparc install for the Ultra5 might be a good choice .

Yeah, Symantec antivirus installs file system filters, but also network layer filter drivers as well. If the console "feels" OK while the slowdown occurs, but everything on the network appears really slow, DEFINITELY start with removal of antivirus software. You do not want network (or filesystem, for that matter) realtime filters on a server.

I think running autoruns from Sysinternals on that box to see what's happening might not be a bad idea. I've got to agree, this is VERY fishy.

OK, I don't know what it is, but I have to respond... Sounds like you did basically the same installs on both. We'll need to know what drivers/apps you put on these two systems, because if they're both acting the same, then they probably have something in common (other than you, of course ). Sounds like something is monkeying with the works - again, we'll need to know what's installed. Also, did you test these right after you installed a clean copy (not vLite'd) of Vista? IE shouldn't crash, WU should work out of the box, other apps should run just fine. Sounds like you've got something on the box Vista doesn't like... Well, again, we'll need to know exactly what's on the box. Drivers make a HUGE difference in x64, so if you're using drivers (and I include antivirus, firewall, etc - they use drivers too) that aren't top-notch, you can (and will) have a very bad Vista experience.Soooooo, all that said, what have you installed on this, both hardware and software, after you installed Vista? And, of course I must ask, did you use vLite on this at all?

I just tried it, and it worked on an RTM build. I'd have to try SP1 too to say for sure. However, you could get yourself into dll hell without WinSXS, so be careful out there .

OK, it appears that all previous slipstreaming advice is.... a little out the window on this. I did slipstream on an XP box to avoid the Vista pid key issues, and here's what I found: 1) Slipstream SP3 over an RTM (or SP0) source - product key REQUIRED during setup 2) Slipstream SP3 over an SP1 or SP2 source - product key NOT REQUIRED (can be bypassed) during setup This was not a VL copy, but a retail copy. I don't know how VL copies will behave, because I don't have one I can easily test on, but I do know that a retail RTM copy will behave differently after SP3 slipstreaming than an SP1 or SP2 copy will behave. FYI, further testing will commence later today, but that's what I've found in three separate slips on 3 different boxes...

Proxy .pac files (just a .js file that acts like a proxy and can be configured as a proxy via GP if you have it on a web server) are meant for this, if you don't have an actual proxy. Otherwise, no, there's no easy way (other than a proxy local hack) to do this in GP, because this isn't really a feature of the browser, it's a feature of a proxy server .

You should be OK if you demote it away via dcpromo, but it's always good to go into DNS on another DC (assuming your DNS is AD-Integrated) and make sure all of the references under the "underscore" DNS folders are gone. Also good to make sure it's gone from your replication in AD Sites and Services too, if necessary. Otherwise, it's pretty painless if you've no clients using it.

I moved it because it's software, and can run on OSes other than W2K. I'll create a link to that from here, but it doesn't belong here specifically when there's a forum more suited for this sort of thing.

Assuming this wasn't an nlite'd/modified install?

This can also be caused by misregistered ieframe.dll and/or shdocvw.dll, re-registering can fix this if that is the case. Also, if you try to install IE7 and then any hotfixes without rebooting, this can happen as well (and it's also an ieframe/shdocvw issue as well). Let us know what happens.

I posted a suggestion to your original IE7 crash post.

Seriously, an error in IE hitting kernel32 could be ANYTHING. Get a memory dump from Internet Explorer crashing, so we can stop speculating .

At this point, I'd make certain that NO ports are open to these INBOUND FROM the PIX firewall, and that only necessary ports for internet access are open OUTBOUND TO the PIX firewall as well. This should limit your exposure, although having a box fully patched (and potentially running antivirus software at the current moment) is a good thing too.Good luck.

System Rebuild complete, rebuild in offiline, then fully patched, also blocked all direct internet access... Till now no more hack, If there is any new vulnerability on 2003 server, then i am sure they will hack again, coz our external ip are same.. Now we just ahv to wait untill next attack.. Thanks for your kind help.. JusThinK Are these proxy servers behind a firewall at all?

I've not seen that particular one before - looks like some sort of remote hack though. Again, I'd rebuild those boxes, but cleaning them offline might be sufficient if you can't afford the downtime associated with a rebuild (although, you'll never be sure they're completely clean without rebuilding...).

At this point, if it isn't working, I'd say getting a network trace (or making sure your router or ISP is allowing TCP port 123 outbound/inbound) would be a good starting point. http://www.techexams.net/blogs/jdmurray/sy...th-the-internet

I am indeed looking at why slipstreaming 5512 behaves differently than my pre-build ISO from Microsoft, although I'm not spending more than a few minutes a day researching it. I'll know more when I know more - if anyone else figures it out before me, post it here .

Installation of SP3 on an installed/running system requires SP1 or SP2 to be installed. Slipstreaming/integrating SP3 into an XP source offline has no such restrictions.

I know nothing about Vista compatibility in the application, but it does mean it's causing your crashes. However, the .dll is from June of 2005, and Vista released November 2006, so I'd say Vista compatibility wasn't necessarily designed into the product (possible if they wrote it for a beta, but a good deal changed from June 2005 to November 2006).