Reread my review from above... print it and keep it by your side.. tuck it under your pillow.. (well, maybe not that!) ;\)

Here's the main concept -

Use a UDF to evaluate a list of resources - is the user authorized to access the resource? (inGroup, InSite, InOU, ComputerInGroup, ComputerInOU, InSubnet, etc...) The resource list should be maintained externally so you don't have to keep hacking your code every time a resource is added, changed, or removed. Embedding data-specific logic in your code is a bad idea in most cases. Login scripts have very clearly defined requirements - "Is a user or computer authorized to access a resource?" Since these authorization methods are limited and standardized, you can develop a short set of rule-checking processes to determine if access is allowed. Throw away any resource record that isn't authorized.

Use another UDF to map your resources. The UDF handles the errors, logging, recovery, etc, and simply returns SUCCESS or FAIL. If the MapResource UDF handles everything, it really doesn't matter what the main script does with the success/fail result.. for example:

PHASE 1 = identify resources to be mapped. Ignore anything that isn't authorized or available, which leaves you with a short list of resources to map.
PHASE 2 = Enumerate the resource "short list", calling a MapResource UDF for each resource. Pass the resource data set (resource type, UNC path, target, description) to the MapResource function. This then decides what kind of resource it is, how it should be mapped, and which parameters to use. This handles the error trapping & logging, simplifying the main process and centralizing the code.
PHASE 3 = Almost unnecessary - either exit silently, or say "errors were encountered - call the help desk!"

Our script employs such methods. The code is compiled, and the same code is used at hundreds of different clients. We can process a set of around 250 resources, including 4 lookups with anywhere between 150 and 480 entries each in less than 5 seconds. That means, when someone logs in, we check almost 250 individual resource records (40 disk, 200 printer, 2 message, and 6 command at this larger client site). These checks run quickly and generate a "short list" of about 16 resources that are actually processed. Most users get about 9 drives, 2-3 printers, display 1-2 short messages, and run 2-3 brief commands.

The lookups translate macros in the resource record data to UNC path fragments based on various values. This alone can eliminate dozens of lines of coding. For example - when a user enters a branch office and logs into a computer, one of the lookup resources determines which OU the computer is in. The lookup translates the OU name to the UNC path of the server in that branch where the applications reside. It doesn't matter what OU or group the user is in (of course, we make sure that the user is authorized to access the data before we use a computer-based lookup).

Point is - employ UDFs, externalize data, and standardize the authorization logic as much as possible. The result will be a fast and reliable solution.

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