Just for reference..
The login script published on my site is fairly large and complex, and is in use at some fairly large enterprise environments. In the environment I currently support, it's used to make 21 drive mapping decisions (one of which has 340 possible permutations), displays a brief message with a 2-second delay, and runs 3 scripts to set the background (BGInfo), update an intranet icon, and gather some user/application data.
- On a virtual system in the HQ building (where the DCs are) the script runs in under 1.5 seconds - so fast that we had to add a delay process so the information would remain on the screen for 6 seconds.
- On a physical network workstation, the same script runs in about 7 seconds.
- On an older PC, in a branch office connected by a 256Kbps Frame Relay link, running the script (and loading Kix32) from the DC in the HQ building, it takes about 11-12 seconds to run.
As Mart says - the time it takes to run these processes is small compared to having to do it manually, or not have access to the resources and information we gather.
Also (in my opinion) Running Scripts Synchronously is the only way to properly process a login. Yes, it will be 5-10 seconds before the user sees their desktop, but you prevent the user from launching things that could conflict with your login process, or access resources that are not yet available.
I also prefer to run the script visible when it runs synchronously. Most people ignore the messages, but - if something fails, at least you'll have an idea why the desktop hasn't appeared. Most users - when asked - say that they don't pay much attention to the info, but have a feeling of reassurance when they see "that black box pop up" during their login.
Glenn
_________________________
Actually I
am a Rocket Scientist!
