cluberti

Agreed - that's why it isn't recommended to use the file compression or drive compression built-in feature of NTFS on the Windows boot volume or volumes that are used to load apps. Every time the file is accessed a decompress will need to occur (CPU _and_ disk hit), and a recompress will need to occur when the file is unloaded (another hit). Compression is fantastic for saving space, but not so much for binaries that are going to be in use (it will make your box slower, not faster). If Windows is running that slowly regularly, consider msconfig / autoruns as a test to disable non-MS items and see if the problem continues. Removing antivirus and firewall packages as a test is also good, as I've seen many an antivirus and firewall filter driver completely lag systems to the point they become unusable, and disabling the driver in device manager (view hidden devices) "fixes" it. A reinstall is usually all that it takes to get around that, but another something you can test.

This is entirely possible, but yes, guest access during the build is required unless you have a network boot CD that loads a client (like the Microsoft client) that can auth from DOS-based networking. However, once a drive is mapped in DOS to the share containing i386, it works just like a local install and the installation media only needs to be available during text-mode setup. Once it reboots into GUI setup, all of the files necessary will have been copied locally to the server's hard disk. When I used to do this a long time ago, I used Bart's network boot disk, although any net boot disk or live boot CD with network support should work.

If you've got an Open license or MSDN sub, there is such a thing .

No, this is a localized version of the OS. You can change English versions (via MUI packs) to load other languages, but not the other way around (spanish will always be spanish). This changes in Vista (the whole OS is language neutral), but in XP/2003 and other downlevel clients, localized versions are not able to be changed.

First, grab this file and copy it down to your box - you can type this in Windows explorer or Internet Explorer and save the file. \\mea.ey.net\SysVol\mea.ey.net\policies\{D1BOEE4D-7794-4B53-A774-BE31COC283A1}\user\scripts\logon\scripta\TP\remove.vbs Then, post the contents here in a code blob or attach the file to your post, and then we can see what's on line 6.

At this point, I can't say anything other than get a userenv log and a network trace, and see what's really going on...

Actually, they shouldn't . I'm not sure about the OWA logon before RPC over HTTPS, but it could have something to do with creating the kerb token in the AD for the user before they can use the RPC proxy to use the mailbox. I'm not sure on it, but I think it's a valid educated guess.

PC Wizard 2008 is able to determine (probably via the PCI vendor and hardware identifier) that it's a SATA device. Windows shows it as a SCSI device because ( a ) there's no real "SATA" bus identifier in Windows XP, just IDE and SCSI, and ( b ) Windows displays devices in device manager by type and bus, and nothing more. There's no discrepancy here. I would suggest using hdtune to determine the NCQ status of the drives in the box - but you'll have to look at the SATA controller's manual (or the mobo manual, if it's built-in) to determine from the BIOS if it's enabled or not.

I hate to sound like a broken record, but the memory access appears to be coming from the antivirus product. You'll have to either ( a ) use a different antivirus product or ( b ) report the problem to Grisoft and get them to fix it if you want to continue using AVG.

UAA = Universal Audio Architecture, the driver that allows XP to be able to use HD Audio chipsets. This is NOT a public hotfix (which is why you need to go to the article I linked and request it), which means you don't get it from Windows Update.You'll need that hotfix installed before XP will recognize your HD Audio chipset.

Are you using the same certificate for OWA that you use for RPC over HTTPS?

I would check to see if you've implemented any keep-alives, otherwise the socket is going to close without continued usage.

If you don't worry about bandwidth throttling, then something like the analogx proxy will work for you.

SATA chipsets are installed under the SCSI bus in Windows XP, therefore SATA controllers not in legacy IDE mode will appear as SCSI controllers, and SATA drives on those controllers will appear as SCSI drives. Answered above. NCQ will improve performance, but only if the SATA controller and the SATA drive support it and you enable it in the SATA controller's BIOS (unless permanently enabled, which I've not seen done yet on a SATA controller). Again, you aren't going to get "rid" of SCSI, see above. The disk drive's cache is accessed and used by the disk's controller and the drivers, Windows will have nothing to do with it. Windows knows nothing of the drive's cache, and has no mechanisms to access it directly - it's supposed to be there to speed up disk accesses through the disk driver, and as such the driver and the disk controller/disk need to work to make use of it, not the operating system.

Wrong. To the OP, it would be wise for you to visit this link and request the UAA patch for XP. Without it, your HD audio isn't going to work no matter what drivers you use.

You can easily create a proxy, but not get any QoS functionality. If you want both, it won't be free (and it'll be a hardware solution) unless you want to build up a Linux box for the task.

What's the stepping on that chip? From what I understand, you need an F2 or F3 stepping processor with support from the BIOS for hardware virtualization before hyper-v will work. I don't know if you have an F2 or F3 chip, and I'm really not sure about that motherboard (you aren't the only one stating it doesn't work, I googled it, so it may not be ready to go). I'd check with Gigabyte, and also find the stepping of your processor. If it's not F2 or F3, stop looking now and get an F3 chip.

From the parameters referenced, it looks like a kernel-mode driver tried to write to an invalid memory address location, and that's obviously a no-no. Without looking at the dump file itself in a debugger I can't tell you more, but the initial indication is a driver failure. Since you were doing a virus scan at the time, you would have virus filter drivers and your disk drivers actively in use - I'd start with the virus driver and get an update from the vendor, if one exists. i was using AVG to scan for virus, and what do you mean by virus driver? and what should i do with the huge dump file..? Are you using the latest version of the product and it's supporting files from Grisoft? What I'm suggesting is that you contact them (maybe an email to their support email address or something), or search for a newer version and update. Most virus scanning applications use a driver - either loaded in kernel or hooked into certain APIs from user-mode - to scan.

Change.... how? Please lay out your problem in a more understandable manner for those of us not privvy to your mind's workings .

Does the user who uses that machine regularly have the same logon speed issues when logging on at the console?

Might want to give this a try - I've not used it personally, but I have used other scripts from that site with success.

Not only that, but the NonDriverSigning value isn't used in anything but Win2K - it's ignored in XP and 2003 sysprep processing, so that might well cause problems too.

Sounds like a lot of work, when it might be easier and more time effective for you to acquire a router that has QoS functionality.

If you have a laptop (or can borrow one) with a wireless card, you may also want to view the wireless levels in the area you want to see what kinds of interference you're likely to encounter on the different channel bandwidths - I suggest netstumbler for this as well. It'll help you use the best channel and perhaps choose the best location for your WAP as well.

This happens with iastor.sys all the time as well, and has been explained here previously. Hopefully that helps you some.