On the one hand, I love scripts. I write or mangle Perl and bash scripts almost every day to do small tasks here and there. Perl can easily handle large, relatively complex tasks, such as Active Directory manipulation or hi-res time sensitive stuff.
But for drive mapping?
I guess I just find KiX ponderous. There are plenty of other logon script solutions out there, but the free KiX language is easily the most prevalent. As languages go, KiX makes easy things annoying, and hard things impossible. I can read from and write to the registry. Can I match on a key and manipulate it based on it's value? Not so much. If I have several exception users, I either define more groups, or manually modify the script per-user. I could write a function to call a specific script for that user as well, but this is only modularizing a flawed concept. Besides, even drive mappings are just cumbersome, with a single properly-written mapping taking several lines:
;? "Mapping I: -> \\example.com\network\engineering"
IF InGroup ("Engineering", "Electrical Eng", "service")
USE I: /DELETE /PERSISTENT
USE I: \\example.com\network\engineering
IF @ERROR = 0
? "I:, \\example.com\network\engineering -> mapped"
? "I:, \\example.com\network\engineering -> NOT mapped"
There are several ways to fix this.
1) Improve KiX
This could be the answer, but as KiX gets more specialized, it must avoid being more cumbersome that it currently is.
2) Finally fully integrate logon scripts into AD
This one is intriguing. How about if I could add objects to individual user and group properties to designate printers that the user or group should map upon login? Matt Prigge came up with this while we were working on a particularly challenging Windows NT to 2003 migration. The problem lay in that about 100 hosts in a production facility were mapping printers based on registry keys stored and referenced by a custom Oracle application that were dependent on the local
installation. Thus, we had to match on a key and replace a value with another determined from the current value, which could be anything.
Since part of the migration included complete printing subsystem overhaul, and all the queues were moving to another server, this presented a problem. The facility was working 24/7 as well so production halts were not an option, rendering the problem larger.