DRIVE MAPPING
Define a set of "user mapped" drives - drives that the users can freely use for "ad-hoc" mapping
Either:
- Unmap all drives execpt for those in the "user mapped" list before mapping
or
- Use a function that will "soft map" - will unmap if the path doesn't match, but will not "re-map" if the drive is already correctly mapped.
Option 1 insures that drives reserved for admin-managed mappings won't be used, while option 2 helps performance. Our login script uses a combination of these to enforce the network configuration while maximizing performance.

Externalize your data - read your resource items from an INI file instead of hard coding the mappings. When the parameters are part of the code, you open yourself up to problems, since every time you change a mapping or resource, you're modifying your code. Our script is in use at hundreds of clients without any code change by using external data. A mis-configuration in the config file affectes only that resource, not the entire script.

You use M: for several mappings. This in itself isn't a problem, but you base your decision on group membership. What would happen if a user was a member of multiple groups? What I DON'T see is any method to handle that situation.

Use a UDF to map your drives, which will check the result code and handle error conditions. It simplifies your actual mapping process.

SCREEN RESOLUTION
Setting screen resolution might be an ADA issue, unless you have an application that requires a specific screen res. If this is the case, doing it from a login script isn't a good idea because it only happens on login. You can control this via GPO, which not only sets the resolution but prevents users from modifying it.

APPLICATION INSTALLATION
Just a bad idea for a login script, on so many levels. Users require admin rights on their PC. You say this is "for a client", so I assume you might want to write something that can be used at other clients with little or no modifications. We use the login script to detect when an application needs to be installed/updated, and it writes a request file to a server. That server monitors the folder, processes the request file and uses the task scheduler to install the application from a network share using admin credentials, the install starts during the login process, but runs out of the user context. This way, the user cannot affect the install process, even if they log off! The result - having a user detect and begin an install is almost the same, but it works regardless of their local rights.

Users have the ability to read just about anything. Collect your data and write a file to a central server share somewhere. You can use that data to trigger installs, but you can also collect asset and configuration data you might need for various IT reports.

RUN is an asynchronous process - your login script will have no ability to check its progress, determine if it was successful, or prevent it from being terminated. Further, you run "installclient.bat" and then, while it is running, you run "patches.bat". This could cause havoc if you are trying to patch the product you are installing.

OTHER COMMENTS
At the end of the script, you set $training = @Hostname. I'm not sure why you need a FQDN unless your training PCs are in a different domain. If that's the case, I might handle this entirely differently, possibly even with a separate script.

You don't declare your variables.

Exit what? Exit requires a value.

Most Kix commands return an exit value. Some are positive logic and others are negative logic, which mirror the error status. Checking is easy - for positiv logic, use:
 Code:
If Not function(blah)
 ; error occurred - check error and attempt recovery, or display message
EndIf
- just remove the "not" if the function uses negative logic.
You need to evaluate these result codes and determine if they were successful. If they arent, you need to write code to handle the errors, either retrying or logging the error and presenting an appropriate error message.

When logging, I'd be very careful about using UDFs that repeatedly open/close the file. We open log file(s) when the script starts and write to them as needed. Alternatively, expand a variable with messages as needed, and write that variable at the end of your script. You could lose your messages using this method if Kix crashes, though. The single open/close with multiple writes is much faster. You will likely notice the performance gains when communicating over WAN links. This simple change reduced the login script processing time from 80+ seconds to less than 15 seconds on a WAN link at one client.

Login scripts affect every user on your network in an up-close and personal way. They need to connect the resources that the users need with minimal overhead. They need to be fast, unobtrusive, and above all - reliable.

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