We're doing exactly that with .VBS scripts. The primary job of our login-script is to map drives based on group memberships, and even that requires a pretty hefty script. The fact that VBasic can only call the SamID (a.k.a. "Pre Win2000 name") of groups has caused some issues with longer names. We'd like to use PowerShell for this, but that requires PowerShell be ON every device which is not the case with WinXP.
We're avoiding compiled code due to the complexity of maintaining such systems. A script-file can be edited by anyone with the right access using nothing more than a text-editor, which makes quick changes a lot easier.
We're also making a conscious effort to use Group Policy to do config-work like modifying registry, file copies, installing software and the like. By doing it with GPO, it makes it vastly easier to work around the permissions problems. Microsoft's Desktop Optimization Pack includes a very nifty Advanced Group Policy Management module, which really helps keep GPO-hell under control. Users submit changes to approvers, and approvers publish the changes as needed, and there is full revision control as well!
Having been a Novell shop until relatively recently we were very used to using the Login Script for fully modifying the user environment. We did everything:
- Drive mapping.
- Importing key SSL root-certs.
- Automatically converting clients to DHCP.
- Upgrade Novell Client versions.
- Upgrade anti-virus versions.
- Check for certain critical Microsoft patches, and report on them via logging.
- Force Windows Update settings.
- Handle reminder-prompts for upcoming password-expiration.
- A handful of custom registry tweaks.
And like you, most of the above was handled through custom-compiled VB6 code. Because of our NetWare servers, .NET code barked about trust-zones so we couldn't use newer code. So we've been where you are now.
When we made the switch to a fully Windows/AD environment we decided to keep the drive-mapping portions in our new login-script and leverage the Microsoft-native tool for pushing workstation config: the GPO. The new AD login-script does just the first bullet point, everything else is handled through GPO or ignored (in the case of Novell Client upgrades ;). Some of it, like the software installs, works much better since it doesn't require the logged-in user to be a local admin. Others, like the Win Update and SSL Certs, have native hooks in GPO which makes them easy as heck.