26

When I worked as an administrator in my first job, I was frustrated that our administration processes with Windows servers were a series of point-and-clicks; we could never match the level of efficiency with the Unix servers which had a group of shell scripts to automate a lot of the work. I soon read about WSH and ADSI and wasted no time learning just how much automation I was able to achieve with scripting.

There was a huge problem though - almost none of my Windows colleagues were really interested in learning scripting. They seemed happy with the manually mouse-clicking chores and were never excited at the prospect of using scripts to do the work on their behalf. I struggled to convince them to pick up scripting skills despite the evident increases in efficiency. I left that job in pursuit of a full-time software development career thereafter.

Almost a decade on working in various environments and different customers, I still encounter Windows administrators mainly possessing this general "mood" where they would avoid scripting as much as possible. Despite the increasing level of accessibility Windows server technologies are opening up for scripting and automation. I am almost certain the majority of administrators are administrators precisely because they absolutely hate performing any kind of programming duties. What are some means to encourage and motivate administrators that scripting can really help them in the long run?

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
icelava
  • 870
  • 4
  • 13
  • 28

13 Answers13

21

As a Unix and Windows administrator who does a lot of Unix scripting and almost no Windows scripting, I'd say that it is in part due to the incredible awkwardness of Windows scripting utilities and APIs, and the difficulty (maybe non-obviousness would be a better word) of running things remotely on a Windows machine.

I mean, WTF is this?

Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Part of the problem, I think, is that there is an API. Under Unix, admins are largely scripting the automation of command-line utilities they already use. Under Windows, you have to use this API that is unfamiliar on every level. For example, what does "impersonate" mean? This is a trivial concept to a Unix admin, who is likely to use sudo and su and be familiar with setuid scripts already. But a Windows admin is unlikely to be familiar with any of that; they might know about "runas" (or the equivalent GUI option), but they are far more likely to log in as an administrator when they need to do something admin-y.

And the documentation on scripting in Windows is miserable. For one thing, it's far more "interpreted language" than script, again because they are using an (unfamiliar) API and not commands that they're already familiar with. But I don't think I've ever found anything useful in Microsoft's documentation that wasn't led into by finding someone who was already doing something close to what I wanted that pointed me in the right direction. Nowhere does there seem to be a list of things-you-can-do. It's like you already have to be familiar with Windows internals in order to do the most basic things.

Not that Unix scripts don't often look like line noise. But a Unix admin can start with a script that does nothing but run simple commands that he already knows. ("I always have to run these three commands in succession. If I just put them in a file together, I can do it in one command!") And then he can later progress as he gets comfortable with the situation. In contrast, there's no way for an admin to script "log into server as administrator; click on Start → Settings → Control Panel; double-click System; click on the Computer Name tab; etc." Yeah, whatever he was trying to get to is probably presented through an API somewhere, but there's no way for him to incrementally find that.

So, to answer the question "how can we get Windows admins to do more scripting?", the answer is, make scripting less alien. How to do that, I don't know.

Honestly, the answer is in Microsoft's hands. There's no reason that they can't have a command line utility to do everything that's done via GUI. (There are actually a lot of them out there now, but they're not advertised, they're poorly documented, and they're inconsistent.) There's also no reason that there couldn't be some hint in the GUI as to what that button actually does. Have a tooltip that shows the API object that's being modified. Or document it in the Help window.

There's no problem in shielding users from the internals, but Windows seems to go out of its way to actively hide those internals, even from those who want to find them.

wfaulk
  • 6,878
  • 7
  • 46
  • 75
  • 16
    Conversely, WTF is this? `ls -1 *old* | awk '{print "mv "$1" "$1}' | sed s/old/new/2 | sh` – squillman Oct 02 '09 at 14:36
  • 4
    Good point on the fact that windows scripting - particularly VB is very awkward until you start to figure it out. The how - well PowerShell has gone a long way to making it more admin friendly. It's closer to Bash scripting than VBS. – Zypher Oct 02 '09 at 14:43
  • 2
    BTW- just playing devil's advocate :) WMI is ugly... – squillman Oct 02 '09 at 14:49
  • 1
    LOL. First, who the hell would do that? Second, the admin is at least already familiar with `ls`. Third, I would consider `sed` and `awk` to be relatively advanced, and certainly in the same arena as the Windows APIs I'm talking about. Third-and-a-halfth, while some (many) Unix scripting commands are complex, you don't have to start there — you can do simple things like simply have a list of commands you're already familiar with — whereas if you want to do virtually anything with Windows, you have this huge learning curve to scale first. Updating the answer, though. – wfaulk Oct 02 '09 at 14:51
  • I have been stradaling the line of Windows and Unix System Admin for about 4 years now. I have to agree, the big difference is the level of complexity of basic scripting. The Bash scripting is completely functional as it is just a list of commands. If you know *nix, you know how to write a basic bash script. VBscripting is diet VB, and most WinSysAdmins are not VBcoders. A – breadly Oct 02 '09 at 14:57
  • You can hack together scripts using "CMD.EXE" that bear a close resemblence (albeit, in the way that a single-engine propeller plane resembles a jumbo jet) to "traditional" shell scripting in Unix. You don't have to use Windows Scripting Host to "script" in Windows. – Evan Anderson Oct 02 '09 at 15:01
  • @Evan Anderson: True. But the set of Windows command-line utilities is ridiculously small, often obscure, and Windows admins just don't do things that way already. A recent update touches on this. – wfaulk Oct 02 '09 at 15:05
  • Every piece of that is something a Unix admin would already be familiar with without doing any scripting. Putting the pieces together is trivial once you learn to use the tools. The command line tools just lend themselves naturally to scripting in a way GUI tools never will. This is probably why the new Windows server tools are being built on top of PowerShell. Expect soon to see tools that will let you record a sequence of GUI actions as a PowerShell script. – Brian Oct 02 '09 at 15:06
  • 3
    I like the way that when you do something in a GUI in Exchange 2007, it just generates a PowerShell script and runs it. – Richard Gadsden Oct 02 '09 at 16:20
  • @squillman That is one poor example of shell scripting, because a.) it pipes awk into sed, when one or the other is quite enough to do the whole job of both, b.) it doesn't use full paths for common commands and c.) the whole thing could have been done in ksh or bash without invoking awk or sed at all. – kmarsh Nov 11 '09 at 19:19
  • Bash Scripting is closer to Batch Scripting (or PowerShell), where they deal in commands. VBScript works via APIs. Yes, it's ugly, but it's possible to do a lot with it... https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report and https://github.com/gwaldo/Microsoft-Exchange-Server-2003-Monitoring-Script for examples. – gWaldo Nov 19 '11 at 05:08
  • @gwaldo, to be more accurate, only executables directly call APIs, and windows scripting host script (vbscript being one of them) uses com objects to automate more that regular executables. Bash scripting is not like powershell except that both happen to be scripting implementations. – Jim B Nov 19 '11 at 05:48
8

Give them a task that can really only be done through a script - for example, I once had to script the creation of hundreds of folders and custom permissions for each folder and it had to be updated DAILY. If they were to do this manually, it would be their sole job. The script, which used CACLS among other things to reset permissions based on the output of a delimited text file, took about a day to perfect (the basic script was done in about an hour).

When you start seeing what you can do with scripting, it can be a huge win.

Multiverse IT
  • 1,825
  • 9
  • 11
  • +1 Great point, there are things that just can't be done by pointing and clicking. – squillman Oct 02 '09 at 14:42
  • yes the scripts i wrote back into those days automated the created of directories, DACLs permissions, IIS site setups, etc. But my colleagues weren't motivated by that. Took one of them two whole months to learn how to write a script function to return a date in string format. – icelava Oct 05 '09 at 01:48
  • PS, as you probably know, don't use CACLS, use XCACLS, or your ACL inheritances break. – Richard Gadsden Nov 11 '09 at 16:59
5

I once hired a sysadmin who outright refused to do any 'programming' I tried to show him the way in leading by example. The best I could get out of him was to use existing code & modify variable assignment or host names ect. to get a job done. Some people are just not bothered with programming, so you need to lower the barrier for them.

Microsoft is making in-roads into this. In SQL Server, it's been possible for a while now to click on stuff in the Management Studio GUI & then dump out a t-sql script of what you've just done. This is great, especially for the not so programming inclined windows sysadmin.

I've noticed that System Centre Virtual Machine Manager has the same view script feature, except it dumps out a powershell script. I think many other product lines are also introducing this.

How to motivate admins into scripting? tough call, a good admin is a lazy admin & that means an admin that will script as much as possible. An admin that has the time to click on things isn't very productive! Overload your admins with so much work, that they have no choice but to script.

Nick Kavadias
  • 10,796
  • 7
  • 37
  • 47
  • How dare you call me lazy?! Oh, wait... – squillman Oct 02 '09 at 14:55
  • 6
    laziness is a virtue for the sysadmin! – Nick Kavadias Oct 02 '09 at 15:06
  • Helllllll yeah! – squillman Oct 02 '09 at 15:20
  • 2
    In my experience, most admins just continue to overload on manual clicks, and take longer than ever to complete their work. :-) I think there are different categories of laziness, some are lazy to think and just wanna click brainlessly; some are lazy to click and think to reduce that. – icelava Oct 05 '09 at 01:59
  • at which point you show them how you can replace their job with some code, they cry from the shame & change their ways... or they don't in which case you fire them. – Nick Kavadias Oct 07 '09 at 23:00
4

I wholeheartedly agree with your post. Unfortunately, I don't think there's much that can be done without support from management and processes in place that enforce using scripts. Given a choice, people will always go with what's familiar and what's easy. At times, this may seem like a negative point, but there are times when simplicity and familiarity is a plus.

On the one hand, the Windows system is implicitly meant to be simple/easy while Unix/Linux systems are much more difficult and less forgiving. So who can blame the admins for taking the path of least resistance? While you, or I or numerous other people may recognize the power of scripting, people will eventually learn one way or another. Typically, admins who holdout on scripting learn the hard way. I like to work smarter, others may just like to work.

What are some means to encourage and motivate administrators that scripting can really help them in the long run?

I used to think you could motivate people, but the reality is unless you're in charge of them the probability of successful "motivation" is extremely low. My attitude these days is: those who want to learn, I will help. Don't be a salesman for a product no one wants regardless of whether they need it. When you help/teach just one person who is motivated (for whatever reason), they will be the catalyst for change. Not you. Just my two cents.

osij2is
  • 3,885
  • 2
  • 24
  • 31
  • 1
    +1 You can lead a horse to water... – squillman Oct 02 '09 at 14:45
  • 2
    ... but you can't make him water ski. – osij2is Oct 02 '09 at 14:47
  • @squillman: You said exactly what I was thinking. My take on this is: If you have a skill that others lack, use it to market yourself and get ahead (whatever that means to you). Helping others get ahead is certainly admirable, but you can't drag them kicking and screaming. – Evan Anderson Oct 02 '09 at 14:58
  • @Evan: Do you think that teaching a *willing* learner is contradictory to "market yourself and get ahead"? If one of the Windows admins were to ask for my assistance (scripting-wise), I'd be hesitant towards doing so but ultimately doesn't teamwork mean going that extra mile an helping them? Just curious to read your thoughts. – osij2is Oct 02 '09 at 15:46
  • @osij2is: Why would you be hesitant to help out a coworker? – wfaulk Oct 02 '09 at 16:57
  • @wfaulk: *Sometimes* people/coworkers are not worth the time or effort. Granted this varies from places/people, but unless a manager/lead has directed you to aid someone else, at times it can be a burden to help someone else out. I realize my question is a bit baffling but keep in mind I do *want* to help out, but sometimes my help isn't wanted or necessary. I'm curious to know where the line lies (for some people) in helping out another vs. saying no. From a career standpoint, helping *should* be beneficial for you and the organization but I've often found that this is not always the case. – osij2is Oct 02 '09 at 18:43
  • 1
    @osij2is: I'm guilty of helping "willing learners" to such an excess that I've definitely squandered some "opportunities" to bill more hours, make more money, etc. One of my "missions" in life is to advance the use of computers such that, ultimately, it might make somebody's life better. If someone comes to me with an earnest desire to learn I'm more than happy to pass on whatever I can. Having said that, if a "fix" w/o a transfer of knowledge is what's wanted I can do that, too. Sometimes it makes me sad not to be able to "teach a man to fish", but if that's what the situation calls for... – Evan Anderson Oct 03 '09 at 04:28
2

A mantra I go by is "Work smarter, Not harder". Doing any process more than a few times means that there is usually a way you could script it out to have it done automatically with a mouse click, bash script, or other method. The way I see it, this personally frees me up to do more important tasks that are not so much the "manual labor" of system administration.

Those who want to avoid scripting may have several things running through their head. Perhaps they enjoy the GUI interface and don't want to learn command line or programming. Maybe they think that by scripting something out they are basically reducing their own self-importance. Either way, this is not the kind of employee I would like to have and a reluctance to do any sort of scripting shows what kind of worker they are. I would rather have a problem solver rather than a "dumb" system administrator.

As far as encouraging and motivating them, I would say just to do as you were doing, show the gains in productivity and how it can make their jobs easier. For some, being a Windows System Admin is just a paycheck, and it is going to be hard to motivate them to move beyond the point-and-click mentality that has worked for them the past 10 years.

Dave Drager
  • 8,375
  • 29
  • 45
  • Good remembrance on the "problem solver"; a lot of folks i meet just want an instruction booklet that tells them what to do for every possibly conceivable problem. They don't want to think about what's happening; just gimme the Step 1-to-23 to resolve this issue. – icelava Oct 05 '09 at 02:17
  • I tend to call those people "button pushers", like noted future blue-collar worker George Jetson. – wfaulk Oct 08 '09 at 04:31
2

There are a couple of issues you have to overcome, you've mentioned one, that a lot of administrators don't want to be involved in programming, even as low level as scripting. The other is related to this, and this is a matter of control. When an admin is doing a task manually they know exactly what is happening at each stage. Many administrators may feel that by replacing this with a script they are losing control over the process, particularly if they don't understand scripting, and didn't write the script (and didn't want to write it).

I think this is more of an issue with Windows admins than Unix ones as scripting has been a big part of Unix administration for a long time and is generally something Unix admins learn from the very beginning, where as Windows administration, and its inherent GUI-ness leads to a more manual process and scripting can seem unnatural.

Unfortunately getting developers over this hump is a hard battle. For the admin to still feel they are in control, they need to understand what the script is doing, and so really need to understand and learn how to script, and the only way you’re going to get them to do this is if they really understand what scripting can do to them

It’s all very well saying it'll make things quicker, make life easier etc, but can you prove it to them? Find a task that they hate, that they have to do regularly and try and automate it. If you can take this horrible task, and make it a single click script, they will love you, but more importantly they may see the benefit of using scripts.

Sam Cogan
  • 38,736
  • 6
  • 78
  • 114
2

[sigh] This is way too prevalent in the Windows world, although I would question your statement about the majority not wanting to pony up and learn to script. The absolute greatest thing I have ever done in my sysadmin career was to learn VB and Perl, which led to VBS, which led MANY other things.

If just showing them doesn't work to motivate, one trick I like to use is to throw out subtle statements in front of management :) Call it sucking up if you will, but it's so not. Show the decision makers the benefits, often it starts proliferating through the group. Don't be a jerk about it, though.

On a more subtle note, it's hard (if not impossible) to change someone. Lead by example!

squillman
  • 37,883
  • 12
  • 92
  • 146
  • 5
    "You know what, i'm pretty sure I can script that so we don't have to spend ongoing manpower carrying that out". Powerful words in front of management :) – Twirrim Oct 02 '09 at 14:41
  • 1
    I've always believed that only in the Windows world can someone call himself (or herself) an admin with absolutely no programming knowledge. Another comment you could drop in is "Why are you doing that manually? That's what we have computers for". – John Gardeniers Oct 02 '09 at 23:21
  • Unfortunately, since i have long gone into a development and consultancy career, the admins i encounter now are mainly those of my customers. I do not always have a chance to make them look bad in front of their management or IT lead :-) – icelava Oct 05 '09 at 01:45
1

Honestly, you can lead a horse to water, but you can't make him drink.

I came up as a SysAd in the Marine Corps about 10 years ago, where there is a wide gap between being an Admin and being a Coder. Being a Coder usually means that you get stuck dealing with the CO's pet project website (getting little of your actual job done...).

Because of this, I resisted learning to code, but once I decided to try it, I had a blast.

As far as drawing someone in, Try using AD/LDAP scripting to lure them in. (I think that it's a bit more accessible than dealing with WMI.) Assign a progression of tasks, say "give me the usernames and email addresses of the people in group XYZ".

I wrote this bit of code to find all users who weren't members of any of the specified groups: https://github.com/gwaldo/LDAP-Inverse-Group-Membership-Report

As far as resources, check out the Microsoft Scripting Guys (who have excellent articles and tutorials) and Scriptomatic2, which I love for digging into WMI.

gWaldo
  • 11,957
  • 8
  • 42
  • 69
1

This question is highly subjective. While I agree with the efficiency and increased control that scripting provides, why does it have to be a mandate? Why do you need to encourage people to use scripting just because you like to use it? Why not let people choose to use the tools they like and prefer?

This question also illustrates a common bias that exists in the IT world: That if I don't script I must not be as smart or as good as someone who does script, and that's wrong. I've known plenty of people who could script better than me, but they couldn't subnet to save their lives or figure out how run a network trace, or configure SQL server to use AWE, or didn't know what the boot.ini file was for, etc., etc.

joeqwerty
  • 109,901
  • 6
  • 81
  • 172
  • 2
    Scripting should be encouraged because it is a proven best practice (nothing was mentioned about it being a mandate, nor do I think it was implied). I honestly haven't seen the "you're not as smart" bias, but I don't doubt that it exists. I would easily dismiss those people as fools... – squillman Oct 02 '09 at 14:39
  • 2
    How is it subjective? Like you said, scripting improves efficiency. There's nothing wrong with a business mandating tools or processes that increase efficiency. There's certainly nothing wrong with a coworker attempting to encourage others to develop a skill that will make them better system administrators. – Brian Oct 02 '09 at 15:25
  • 3
    @squillman, who says it's a best practice and isn't that itself subjective. What's best practice for me might not be for you. Is there a study that says that 90% of corporations consider scripting to be best practice. @Brian: Who says it makes them better system administrators? My co-worker can script but can't subnet while I can subnet but can't script, so who's better? No offense intended, just playing devil's advocate here. – joeqwerty Oct 02 '09 at 16:08
  • 3
    @Joeqwerty: scripting is *powerful* in comparison to point-and-click as scripting (correctly) can do more tasks in less time and more accurately than us lowly humans could ever do manually. Perhaps the phrase should be: "scripting is a *better* practice". Your (devil's advocate) argument is more subjective than the claim itself. "What's best practice for me might not be for you." That may be true, but that doesn't mean it's *not* the best practice. It might mean you *can't* or *don't know how* to do it. That's a different problem in and of itself. – osij2is Oct 02 '09 at 16:43
  • @osij2is: good points, all taken with due respect. BUT, your last statement illustrates the bias I'm speaking of. You say: "It might mean you can't or don't know how to do it. That's a different problem in and of itself." So you have a bias against non-scripters because apparently their inability to script is percieved by you as a "problem". My boss doesn't think it's a problem. I don't think it's a problem. My boss is happy with my skills, productivity, and efficiency so exactly who has this problem because I don't script? – joeqwerty Oct 02 '09 at 16:57
  • Also, how is scripting more accurate? Isn't a lowly human doing the scripting? Are you saying that your point and click skills leave something to be desired but that your scripting skills are infallible and without reproach? This kind of logic doesn't make sense to me. – joeqwerty Oct 02 '09 at 17:01
  • Ditto osij2is, except for the "better" bit. There are all kinds of things that my boss is happy with, too. That doesn't mean they're best practices across the industry. Accuracy of a script is proven over time. Over time (and all things equal), a human will make a mistake that a script doing the same function will not. When you develop a script, and get it to where it's functioning correctly, that script will perform its duty. Yes, a lowly human is doing the scripting but once it's right, its accuracy (over time) is superior. – squillman Oct 02 '09 at 17:21
  • Thanks for the lively debate. Again, I intended no offense, I just wanted to present an alternate point of view. time for me to move on to new questions. – joeqwerty Oct 02 '09 at 17:48
  • I don't script just because i "like it". I script because it _saves_me_time_ in the long run. One whole week to setup a server, or use scripts to configure it in one day. You decide. – icelava Oct 05 '09 at 01:52
  • You know what irritates me about this site? The fact that I get downvoted for having an opposing opinion. Other than that, it's great. – joeqwerty Oct 05 '09 at 02:10
  • 2
    But your opinion is wrong. ;) Seriously, though, I think avoiding scripting is like avoiding knowing how to subnet. Neither one is good. I mean, if you agree that scripting increases efficiency and control, why are you arguing that we should treat as equal those who avoid it? If you were to hire someone to plow your field, would you rather hire the guy with a tractor or the guy with an ox? – wfaulk Oct 05 '09 at 03:22
  • Well I definitely disagree with the fact that I got a downvote simply for expressing an opposing opinion. – joeqwerty Oct 05 '09 at 13:12
  • Well, you have to admit that the question wasn't "should scripting be encouraged", but "how do I encourage it". That said, it *was* _relevant_ to the question. – wfaulk Oct 05 '09 at 16:44
  • Getting a down-vote means disagreement. Getting an up-vote means agreement. It is fundamental mechanics for these sites. If you gladly accept up-votes, you ought to gladly accept down-votes in view that not everybody shares your opinions. – icelava Oct 06 '09 at 02:40
  • Who would you rather hire - the guy who can configure routers in 100 different sites through a script in 30 minutes... or the guy who takes 30 minutes to manually configure ONE router using a GUI web interface for everything? I know who I'd be hiring... And I know a guy who did that very thing working for a bank - the bank alloted 3 months to change all the branches... he did it in 30 minutes. Even scripting ONE system can make sense - IF you can later reuse that script or set of scripts on 99 others. – Multiverse IT Oct 07 '09 at 06:20
  • Let it go already. I've moved on with my life, thanks. – joeqwerty Oct 07 '09 at 13:13
0

I have defined scripts as "Documentation that does the work for you."

Manager: Go spend countless hours creating documentation, that a first grader can understand, that will be stale by the end of the week, for your co-workers to clicketty-click through Task-X.

Employee: I have a script that does Task-X, could I just give them that.

Manager: Sure, after you have finished the documentation I just asked for, document your script as well, with a flow chart.

Nathan Hartley
  • 1,660
  • 5
  • 26
  • 40
0

I have defined scripts as "Documentation that does the work for you."

Manager: Go spend countless hours creating documentation, that a first grader can understand, that will be stale by the end of the week, for your co-workers to clicketty-click through Task-X.

Employee: I have a script that does Task-X, could I just give them that.

Manager: Sure, after you have finished the documentation I just asked for, document your script as well, with a flow chart.

Don't forget that the documentation should be in an MS Word document so as to complicate reading it from the server.

brenbart
  • 11
  • 2
0

The next question: why should they script? That will determine the answer.

Presumably, you script because it's more efficient. In that case, you can either show everybody else up, or point out to management that there's more efficient ways to administer the systems and wait for them to take advantage of that in a cost-cutting measure.

Somebody with authority can mandate scripting, by requiring that there be scripts in place to handle most things. How well this will work depends on several things; if just stated like that the scripts are likely to remain woefully inadequate and obsolete, while the admins work as normal.

There's also the question of exactly how this is affecting you. Does it just bother you, or would your life be better if your fellow admins scripted things?

David Thornley
  • 181
  • 1
  • 1
  • 4
  • The main effect is admins wasting their time performing repeated manual chores on multiple machines - longer turnarounds - which can impact our development schedule (always never enough). – icelava Oct 05 '09 at 01:57
  • 1
    and don't forget that manual tasks are error prone. – John Gardeniers Oct 08 '09 at 11:34
0

I actually had another thought. In relation to the fact that junior Windows admins are used to GUI interactions, maybe it would help if you started them with scripting GUI interaction, with something like AutoIt. This would allow them to get their foot in the door in regards to scripting while still allowing them to use the tools they already know, instead of throwing out their existing tools and making them learn new tools and scripting at the same time.

Then, once they get comfortable with the idea of scripting in general, they can move on to non-GUI scripting. Even if not, though, automating button clicks can still potentially be a big time saver.

wfaulk
  • 6,878
  • 7
  • 46
  • 75