cluberti

I would seriously consider upgrading to R2, as DFS and FRS are a LOT faster in R2 than their counterparts in SP1 and RTM.

No, you should not. A reboot should suffice.

Note that a lot of antivirus... "issues"... show up as using System CPU time - they all use file system filter drivers to do their jobs, so they'll show issues in the "System" (kernel) process. Not saying this is the case (use Process Explorer!), but it could be.

You could purchase a copy, either OEM or retail, and that would then give you a legal copy. Having the COA is nice, but you can't be sure it hasn't been used (although if it has a COA, the CD was supposed to come with it). Technically it would be legal for you to use that key, and illegal for someone else to do so, but only if it's an OEM key (if it's retail, you can't use it unless you purchased it from the person who sold you the machine). I'm also not sure about the real-world implications of activating that key (if it were OEM) would be if someone else has activated that key. You could always call Microsoft's 800# to see if it's a legit key - if so, you could probably use it if it's an OEM product key.

I would suggest taking snapshots of your machine at different times using perfmon. I would suggest downloading perfwiz.exe from www.microsoft.com (to configure perfmon properly via a GUI), and then take a few days of perfmon data after first building the machine, then take another set after a month or two (when you see slowdown) and compare the data. If the machine really is getting "slower", you should see a difference in the perfmon data showing you so, and possibly telling you why as well. Also, make sure you are defragmenting your disks regularly - use the following as a guide to schedule the defragmenter to run on your volumes frequently: http://www.microsoft.com/technet/itsolutio...pog3.mspx#EYNAE

Windows 2003 doesn't have this feature.

That's a very broad question, and perhaps you are unaware that it is . I would strongly recommend visiting the link below to get a better idea on how to implement Windows 200x PKI: http://www.microsoft.com/technet/prodtechn...t/2000cert.mspx

I'd have to second taking a look at the stack on this one, as that kernel32.dll call is done by almost every driver and .dll function on the system. You'd have to look at the call stack of that particular thread when it's in state and chewing up CPU to see what actually called the function, as kernel32.dll is just the victim here, not the culprit.

If you've got an AD, you can use a GPO to set it in the site to zone assignment list.

Shortly after Vista hits the retail channels next year, \P will no longer come preloaded by default shortly after that, again, at least on PC's destined for the home retail market. As far as purchasing OEM CDs though, they'll be around for years. You can still buy Windows 2000 OEM CDs if you do some hunting. Note that retail CDs will likely dry up in the first year Vista is out, as few (if any) more will be going to retailers - OEM will be about the only way to get an XP CD once Vista is out in force.

That's the biggest load of BS I've ever heard. Windows XP x64 is indeed a 64bit OS, and all system binaries running the OS are 64bit. There are 32bit binaries on the system for compatibility (IE 32bit, for example), but the OS is a 64bit OS - otherwise it wouldn't be able to address memory over the 4GB boundary.The WOW 64 (Windows on Windows 64) foundation is just the opposite of what you think - it exists for running 32bit applications on 64bit Windows, not the other way around. Windows XP x64 is not based on Windows XP 32bit, it's based on Windows Server 2003 SP1 (notice file versions are 5.2.3790.xxxx, not 5.1.2600.xxxx). It's been rebuilt/recompiled as 64bit, yes, but not from XP 32bit. I'm not entirely certain about renaming files from ...32.dll to ...64.dll, but I'm fairly confident that this is for API compatibility reasons.

If you're talking about IPSEC communications between AD machines, this may be what you're looking for: http://www.petri.co.il/configuring_ipsec_p...through_gpo.htm If you're talking about using certificates for authentication on the domain, then I think this may help you: http://support.microsoft.com/?kbid=272175 I'd suggest doing both, for security .

Teaming is when you put two or more NICs in the server, and use special "teaming" software (the vendor must provide the software) to make the NICs in the machine appear as one. You'll also need L3 switches that the servers are attached to for this to work properly as well, however.

I thought I made it clear, but I guess not. No, there's no way to do this without being at the machine itself and disconnecting sessions manually. Short answer, no. File sharing works via access gained with a username/password against the machine, not the share itself.

If, after a system restore (removing the modem software) the issue returns with only the modem attached, I'd have to say the problem could then lie with the modem. If you do another safe mode system restore with the modem not attached to the machine, does the problem return after a reboot?

Try system restore from safe mode, that should get you back to stable.

I'm not sure about whether or not it's the best, but it's nice and works well at least for me. You might want to visit planetamd64.com and see what others are using for wireless in x64, as there's lots of good information there on what works and doesn't (and not just wireless). You may find something better for your uses by searching that site for a bit.

I would first disconnect the modem from the serial port, then uninstall the modem software. I would then suggest going back to a restore point prior to the installation of the modem software, just to be safe, and then I would attach the modem to the serial port and reboot. When the device wizard pops up at that point (it should), install the modem driver manually with the CD in the drive (don't install the driver first).

When a remote user accesses the machine hosting the shares, he or she doesn't authenticate against the share, but against the machine itself - once you've authenticated against the machine, you then have access to any shares, files, or folders that account/password has access to, without having to authenticate again. The only way to force re-authentication is to forcefully disconnect the client's connection.

Actually, these symptoms are similar to what happens when the OLE key in the registry goes bad - have you checked your HKLM\Software\Microsoft\OLE against one from a working machine?

The problem ultimately boils down to the fact that Windows doesn't work well with multiple default gateways - which is a pain when you need two NICs for two separate networks. What's happening is all outbound traffic is going to attempt to go through the NIC with the default gateway set - you can somewhat avoid this using the route command, but again, it isn't going to work very well. It would be better to get a device that understands multiple connections (used to recommend Nexland devices before Symantec bought them) in front of the web server, and have it do the routing to and from the web server. That way the web server itself won't need to understand how to route on multiple subnets.

Unfortunately, a Windows machine on multiple subnets can create issues. You could try a second NIC in the machine, but there's no guarantee that it will work properly. It should, but no guarantees.

This link should work: http://www.buffalotech.com/products/produc...81&categoryid=7 No, that device is powered by a Broadcom chipset. You'd need to determine which Broadcom chipset is in that device and use the proper Broadcom driver.

LocalSourceOnCD tells Windows whether the setup files are being installed from a CD drive or not. As far as WDS, you need to run a beta server product (VERY beta) to get WDS - it's very nice, but you won't get the full potential of using it until you use ximage and Vista, and I'm not sure running a beta server OS in a production environment is for everyone. RIS can be configured to do most everything WDS does (although not as pretty), and I always suggest using FLAT installation files over riprep images. Imaging and Windows are still not entirely happy working together, and flat installation images can be tweaked pretty heavily to completely automate from install to logon prompt, so the only real benefit to riprep images (other than getting around installing troublesome software that can't be repackaged properly) is that the install is usually a bit quicker than a flat install.

Does the problem occur if you use the mstsc client? I know you're using a web-based package, but does the issue occur when you're just using the mstsc client to the machine?