Searching for previous install very slow.

Hello all,

I recently began researching the phenomenon of certain win2k FAT clients taking an extremely long time to perform installs due to an excessive amount of time “Searching for Previous Installation…” I found information in a couple of older threads that I have experimented with and wanted to follow up with some results.

First, any figures or conclusions are drawn from an average of a series of trials that were run on three different clients. These clients “Searched” for a period of time from 1 min and 30 seconds, to 15 minutes.

For my environment I found that:
-Tweaking NIC settings (10mb/100mb; auto detect, auto select, hardware default, half-duplex, full-duplex, etc.) did not effect search times. Optimizing these settings did allow for much quicker load times for the executable. Running \\deploymentserver\b7333\OneWorld Client Install\setup.exe yields a “starting setup…please wait” and a “Finding Installed Components”, before providing the installation welcome screen that allows you to click next and begin the “Searching for Previous Installation…”. When not optimized, this “loading” took as long as 90 seconds (not typical). After tweaking NIC settings, this occurs in as little as 5 seconds.

-Deleting old packages from the deployment server and removing entries from the Package_inf directory was not a factor for my test. I already had the packages and directory as lean as possible. This is not to say that this will not affect the process under a different situation.

-Defragmenting the hard drive also had little effect. This may have increased performance slightly, but not enough to offer a percentage increase.

-Disabling real-time virus protection had the greatest performance gain. This improved performance by about 34%. Unfortunately, real-time protection is set on the Norton Parent Server and it is not desirable to allow this to be changed at the workstation level. I therefore, changed the setting back to keep Win2k FAT clients with the same settings as all other user workstations. Changing virus settings to not scan the b7 directory may be an option here.

-I tried turning on the Indexing Service (C:\WINNT\System32\cisvc.exe), but this also has had no effect.

In a previous thread, Mike Trottier (mtrottier) stated, “I have found that the ‘Searching’ process can vary greatly from machine to machine even if the machines seem to be identical in configuration. (anti-virus on or off)”. I have found this to be exactly true! I have two identical workstations:
Dell Latitude C600, PIII 750MHZ, 256mb RAM, 4200RPM 30GB hard drives.
One completes the process in ~1min and 10 sec. The other takes in excess of 12 minutes.

The one conclusion I have come to is that the time it takes to complete the process is directly related to the amount of CPU time allotted to the setup process, ‘_Setup’ in task manager.

The fast workstation allots about 80% of its processor while the other allots about 6% and leaves the rest of the CPU time idle.

Anyone else have any final suggestions?

Thanks


Ryan Hunt
OneWorld XE; Update2; SP17.1_B1
AS400; V4R5
DS: Win2k SP2, SQL 7.0 SP3
TSE's: Win2k(SP2) & NT4.0(SP6a) with Metaframe 1.8

Ryan :

I've experienced this same problem since B7331, and most of my research
matches yours.
I think that most of this time is consumed while looking for files across
the \b7 tree.
Let's discuss the "Searching for Previous Installation..."
a) It takes a lot longer on a machine with Development objects than on
a PC that only has Production objects (spec and bin32). I think that
this is related to a kind of scanning on \include (8000 files), \obj
(6000 files) and \source (6000 files) directories.
b) Delay increases with the quantity of pathcodes.
c) FAT times are worse than NTFS. That's because FAT directory structure
is more primitive (a linear linked list) than NTFS' (a balanced tree).
d) I've tried to delete all obsolete packages from Deployment, but
haven't noticed any improvement.
Ryan is also pointing to important guidelines :
a) NIC settings (fixed speed, fixed duplexing mode) DO matter.
b) 100 Mbps is SO MUCH better than 10 mbps for installing and running Xe.
b) Uninstall NWLink/NetBeui protocol from your PCs.
c) Defragmenting didn't help me too much on workstations.
d) Antivirus can be a pain in your teeth ;-) If you can't disable it
while installing, at least exclude .C, .H, .OBJ, .DDB and .XDB files
from being scanned.
e) Disable FastFind (provided by Microsoft Office) and Index Service.
f) I don't why, but... installing always took me less time on C: disks
than on any other partition (mystery)

Sebastian Sajaroff

Re: RE: Searching for previous install very slow.

Thanks, Sebastian. This has been discussed many times before on the list and, with a recent Antivirus upgrade, has just become an issue for me. This saves me from searching the list.

B733.2, SP 15, Oracle 8.1.6, HP 9000
Win2K, Citrix 1.8, NFuse

Re: RE: Searching for previous install very slow.

Just as an FYI, we have experienced the same issues listed above on 3 new Citrix servers and tried all the same things to remedy the issue. Our Citrix admin reapplied, Citrix SP3 and the issue was fixed. We are still not entirely sure why this fixed the issue but the installs are now faster than the fat clients or other Citrix servers.

XE, SP15.1, HP-UX, Oracle 8.1.6

Re: RE: Searching for previous install very slow.

I have experienced similar problems and have a theory that I have not been
able to test, yet.....

I believe that the problem may lie in the NT user profile that was used to
load or execute OneWorld for the first time.

In the case that the NT user does not have proper authority to the
registry, the registry is partially updated and Setup.Exe must revert to a
manual search to find OneWorld (thus the long time). Adding the authority
after the fact has no effect. Reinstalling OW has no effect. Solution =
wipe the OS and start over.

In the case that the NT user does have the proper authority to the
registry, everything works great!

In our installation, we add the Everyone group to the local Administrators
group on the individual clients. In the case that this step is missed by
accident, we regret it every time there is a package.

Again, this is my theory. I have not had an opportunity to prove it......



B7331 & Xe; SP15.1
AS/400 & NT/SQL




Adam Clark
Corporate Information Services
Office: (626) 434-4275





Adam Clark
Project Manager
Golden State Foods -- Information Services