There have been several discussions on the concept of performing administrative tasks during logon, and why it's a bad idea. You're experiencing one of those bad ideas. \:\)

Not to say it isn't possible, but there are better methods. Admin tasks should be run from an admin location, not from the login script. Users don't always (and shouldn't) have enough rights to access information or perform tasks. The usually DO, however, have the ability to determine IF an admin task is needed..

I recently had a discussion in the forums with Robdutoit regarding this - the concept is to have a process on a server that looks for a file that contains a service request. The login script performs a simple check, and if needed, it creates a request file and then moves it to the server's share. This allows the login script to end quickly. The server finds it, determines the WHAT and WHERE, and pushes an admin task (bat file) to the requesting workstation and then invokes it with admin rights via a scheduled task. The tcLib UDF library can do this with just 4 commands - tcInit(), tcDefineTask(Args...), SetEvent(Host, Taskname), and tcExecute(host, Taskname). Look at the posts he initiated for more on this discussion.

Our Universal Login Script runs in our environment in 0.88 seconds, processing 14 drive and 5 printer resources, a message file, and (if admin) a 1-line Kix script. When we add the "detect and request" task, it adds less than 0.1 seconds to the execution, and the admin task starts within 5 seconds. The longest I've seen our script take on a LAN connection was 9 seconds, and that was processing 40+ resource connections and used six 450-entry lookup tables for Resource Rewriting. That is the client where the Detect and Request technology was first implemented, due mostly to the hundreds of small sites with 128-256K WAN connections.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D