cluberti

I think you'll have good luck with the network monitoring tools, and I too believe that your hardware is not the issue (you've actually convinced me it's your line by stating that web pages load fine but FrontPage takes forever). Again, good luck, and let us know how it goes.

Instead of using psexec (which runs in the context of the locally logged-in user), use the sc.exe command (native to XP) to change the startup value of a service and start the service. It works 100% of the time if the remote user has domain admin privileges.

Unless there's a problem with the RSOP, it'll work.

You can determine the version from the Volume label of the disc, as well as the \i386\setupp.ini file. http://support.microsoft.com/?kbid=889713 Not sure who you talked to within Microsoft, but that's the public KB article.

Well, I hate to keep throwing this at you piecemeal, but you also have to take into consideration that clients use RPC to do most network connections to a server - the initial connection is always made on the endpoint mapper port (135), but that port is only used as a control channel to set up the actual transfer channel on a dynamically assigned port above 1024 on both the client and server. You'll have to force this to use a specific range of TCP ports on both the clients and servers, and you'll have to allow this range in through the firewall at the server end. If you really need a firewall on your DC's, you'll probably have to use network monitoring and watch ports on the server to see exactly what is being opened by your clients. My best suggestion, though, is to firewall external to your servers, and leave the Windows firewall disabled on your DC's (at least). Active directory is a chatty SOB, and it requires LOTS and LOTS of ports open. I seem to remember an article about limiting RPC port ranges on Exchange servers, but it should work for plain jane Windows servers as well if you do really need the firewall enabled on your DC's.

Good luck. Just to shed some more light on my opinions of the issue from what you've told me, I've seen this many times before: 1. There may be some misconfiguration on the client or server end (gateway, router issue, bad cable, etc.) 2. There may be a performance issue with the server itself (the issue should happen to all users, all the time in this scenario, and it isn't now - but I'd still perfmon the box for a few days to see if it's behaving within "normal" constraints, memory/CPU/Disk/process-wise. 3. The internet connection is more than 70% saturated, more than 50% of the time, in which case it's time for a line upgrade. 4. The internet connection has a high latency caused by poor wiring, a routing issue within the ISP's network, a deliberate DDOS attack against the circuit, or just the victim of a long run from the demarc to the ISP's upstream equipment. I've consulted for many, many years, both as a network and a platforms consultant. I also spent many years as a network engineer, so I do speak with at least a modicum of knowledge about the subject. One constant I find with businesses with issues such as these is that they either aren't using a full T1 when they should be, or they're trying to save some money with a DSL or cable connection. Most people don't understand that the performance you see on a network link is affected by both throughput AND bandwidth, and even fewer people understand the difference between the two (they were seen as one and the same by quite a high number of people I met as a consultant). Even an upgrade to a fractional T1 (768K or higher) will result in better performance than a 1.5MB SDSL or cable link for business use patterns such as this - it's not the throughput that affects performance here, so much as the bandwidth available.

The version of Windows you received with your Dell computer was an OEM CD, and more specifically, it was an OEM CD that is specifically for use on Dell PC's. The version you downloaded (possibly not entirely legally, I might add) from emule is likely an MSDN or VLK version of Windows; and since keys from different versions of Windows (OEM vs MSDN vs VLK) are not compatible, it won't work - the Windows setup routine doesn't know what type of key yours is, but it does know that it isn't a VLK or MSDN key. Therefore, it fails. The problem is that your original Windows CD from Dell has a few custom files on it, and you'll likely not be able to slipstream it yourself due to files on your Windows XP CD being different from ones in the SP2 update, which causes the update to fail. You'll need to contact Dell directly to get a SP2 Windows XP CD, or you'll have to legally purchase and install another copy of Windows from a retail or online outlet. There is no "fix" for what you're doing, because technically nothing is "broken" here. Both versions of the Windows XP CD's you have are working the way they were designed by Microsoft - you need the right key, with the right CD. If you buy a PC preloaded with Windows from an OEM, you get a PC manufacturer-specific OEM copy of Windows that may have trouble doing things like slipstreaming (it is not something that is supported on a PC vendor's OEM version of Windows). And to head off your next question, no, there's no (legal) way around it either. Contact Dell and get a new CD (and likely pay for shipping costs), or purchase a non-PC manufacturer OEM version of Windows from another third party vendor.

You should still be able to have network access, even though explorer crashed. Use CTRL-ALT-DEL to bring up the task manager, from which you can launch a command prompt (cmd.exe). Once the command prompt is up, pop in your Windows CD and type "sfc /scannow" and hit enter. When SFC finishes, reboot, and you should have your wininet.dll file back (and any other that are missing, if that is the case). If you don't have your Windows CD handy, you can instead open iexplore.exe from the Task Manager (Internet Explorer) and download the file from the internet - it needs to be placed in your %windir%\system32 directory. Reboot, and hopefully you'll get a full boot without errors.

When you run a scheduled task as a specific user (rather than the local system account), you run the risk of the application not running properly in certain situations. For instance, if the script or program needs an actual user session and desktop heap memory, it will need to run interactively - that gives it a session, with the credentials of the user, and allows it to do things on the virtual winstation that it would not otherwise be able to do. If the program or script is unable to interact with the desktop winstation of the logged on user, it will show either as failing, or continue to run in an error state (and show "running") if it does not have error handling that can error out in such a situation (scripts being the most obvious in this scenario). It is likely that you had the task set to run interactive in scheduled tasks before you formatted, and for whatever reason it isn't running interactively now.

It's just a key in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services - grab one from a working machine and import it into yours. Well, I should say it's a little more than that, but I would doubt the files are missing unless you removed the service via nLite. Assuming this is the case, simply sfc /scannow the box (to make sure all critical system files are installed and in working order), then re-add the service by exporting the dhcp subkey of the Services key, and importing it into your broken machine. Reboot, and it should be back and working properly.

SP2 should slipstream fine onto a disc, whether the key is pirated or not. However, if it is an OEM Windows CD with custom oembios.bin file (and possibly a few others, too), you may run into an issue where the SP2 setup routine is unable to replace these files, and fails. This is likely the error you're seeing, and you'll have to contact your OEM to get updated Windows installation CD's with SP2 on them. It is worth noting that slipstreaming SP's onto PC manufacturer-specific OEM CD's isn't supported - it's only supported on generic OEM and VLK CD's (although it does work on MSDN CD's too).

Yes.

An x64 version of Windows would not install on a 32bit processor. Windows setup would begin, and then fail right away.

You don't have the RPC or SMB ports open either, although the SMB ports aren't as needed as the RPC and DS ports (135, 136, 137, 445). You may want to look at KB articles 224196 and 319553 as well.

Perfmon logs and netmon traces of the server and client when this is happening would be a good place to start. Microsoft has a tool to get you started on perfmon here, called perfwiz: http://www.microsoft.com/downloads/details...&displaylang=en Getting netmon installed at both ends and doing a trace on each machine when it is slow will also give you an idea of whether the data across the wire is just slow, or if one end is having issues dealing with the traffic in some way (you'll also be able to see the contents of most packets as well, which can help). As far as the DOS prompt and accessing file shares, it is very important to note that going through a DOS prompt to access shares and files doesn't require the type of resources and privilege enumeration, both on the client AND the server, that you need to spin up when through the GUI. Using a DOS prompt instead of a GUI to access file shares will be much faster all of the time, not just over slow links. Try it internally sometime - the DOS accesses will always be faster than using Explorer or an application's open or save dialog box (which also uses Explorer.exe, and thus shdocvw.dll, shell32.dll, etc). I'd still say you could have latency issues on your DSL connection that you wouldn't see otherwise - again, only having two channels is still possibly an issue (you've told me nothing that would rule this out yet). Remember that a VPN connection also adds TCP overhead to each connection and each packet sent across the wire. Edit: I need a spellchecker.

Every request made to Microsoft support gets answered. While Microsoft may not be able to help if the problem isn't with Microsoft software, they will do a best-effort to support you with your third-party applications as much as is possible. However, if you want the best support possible, you have to call the support line.

No, but AT commands are good for testing if a Scheduled task is running correctly. An AT command will run as the logged-on user, if that user is logged on, and the /interactive switch ensures that it runs and can interact with winstation#0, or the console. Scheduled tasks should run like that when configured, but they don't always work properly (as you've now seen). It's at least a good test to see if the problem is with the scheduled tasks subsystem, or the OS itself.

I'd say the DSL line is likely the culprit - great throughput, but horrible bandwidth compared to a T1 or DS3 connection. Since a DSL line is only two channels, you'll likely see a performance hit when adding more than 3 or 4 users at any one time. The T1 will have 24 channels (well, 23 usable for data transfer), whereas a DSL line (of any speed) will still be two channels. Having a lot of throughput is nice, but the more channels you have on the line (within reason), the better your line will do under load. Even if both connections are rated at 1.5Mbits, the T1 will perform much better than the DSL, always. The number of channels does make a huge difference when the line gets under load.

Vicomsoft's DHCP product is more lightweight, but if you're going to spend money you may be better served purchasing a cheap Netgear or Linksys broadband router (for about the same price, or less, than the products I stated), as it will provide DHCP services and some firewall security for your network. Edit: I can't spell.

That may also be true in Germany. I guess that's the price one pays for getting Windows cheaper

"re-instal windows without any of the updates that were released after September" That doesn't seem very safe - have you considered contacting Microsoft for support? They'd likely be able to pinpoint the root of the problem, and either help you fix it or point you to which third-party vendor would be able.

If you've got sluggishness on your system, you should consider using perfmon to see what's going on. MS has a cool little utility called perfwiz you can use to configure all the counters for you: http://www.microsoft.com/downloads/details...&displaylang=en Get a few hours of "sluggishness" monitored (preferrably run from another machine), and then take a look at the logs with the perfmon application. Something should stand out (you can send me the file, and I'll look at it if you'd like).

You should still be able to call for a hotfix, even with OEM versions. Not sure how it works in Germany, but you should still be able to request a hotfix.

I second that suggestion. You won't know the PID until you install Windows and check it in the system properties.

If the tasks aren't set to run interactively, you will not see them (and they may not work, if they need to interact with certain portions of the system). Try adding the task using the "at" command (at <time in 24 hour format> <path to executable> /interactive) and see if the task runs.