I spent a better part of two full days banging my head against why a large chunk of my workstations were accessing network resources very very slowly. Some machines ran fine. I did everything I could think of. Upgraded the client, patched it with patch “B”, upgraded the NAL to zen 7, maually entered entries in the host files. Nothing seemed to work. Finally, I realized the slow down happened when accessing anything with a UNC path. To alleviate the issue, I changed login scripts and zen apps to run from mapped drives instead of UNC paths. This helped for the most part, except for GroupWise, which is run from the app launcher with PO switches.
Through all the mucking around, I missed the biggest difference from the machines that were working fine, to the ones there weren’t. The PCs running XP SP2 were fine, anything else wasn’t. Upgrading to SP2 seems to fix the problem. Everything should be patched anyway, but that isn’t exactly possible with the amount of PCs we have that aren’t correctly configured for our Zen setup(which is a work in progress to get them there). What, in SP2, that fixed it is beyond me. What is even more perplexing, is what caused the issue. I can pin point where things went wonky, but I can’t figure out what caused it. We got a new ISP, so instead of cutting it over to the existing BorderManager box, I planned on moving everything piece meal to a newer server. The issue there, was that every workstation used the border box as a proxy server with a static IP. So instead of changing every workstation, which wasn’t feasible due to my zen workstation situation, I decided to give the new border box the old border box’s IP. Once I did that and repaired the network addresses through DSREPAIR, the problem began to occur. The only reason I can come up with why that would cause issue, was because the new borderbox is acting as the root master for eDirectory.
I’m still at a loss to what caused it, and what fixes it in XP SP2. At least there is a fix.