Scripture, or the simple things

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 pr

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"

ELSE

color y+/n

? "I:, \\example.com\network\engineering -> NOT mapped"

color w/n

ENDIF

ENDIF

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.

After testing the theoretical limits of KiX, the decision was made to write the script in Perl and statically compile it. The upside? The script worked like a charm, modifying the keys as needed, mapping drives, printers, and so forth. The other upside? Matt snuck in printer mapping through the LDAP object description field. The printer queues were listed in the description field of the object properties, and the script would parse that field and map the corresponding printers. Natch.

Why isn't this already available? Why can't I assign drive letters and mappings in AD and have them work as expected? It wouldn't be difficult. DFS links are in AD, and for non-DFS shares, manual UNC configurations should be simple.

I don't want to see login scripts disappear, mind you, since they provide the only method to achieve certain enterprise-wide system changes, but the most common elements are drive and printer mapping. Taking care of those would reduce login scripts to their intended role: exception management.

I'd love to see a Login Settings or Drive Mapping tab in the AD object editor.

Wouldn't everyone?

Recommended
Join the discussion
Be the first to comment on this article. Our Commenting Policies