Servers

Nine traits of the veteran Windows administrator

A recent post about the traits of veteran Unix admins convinced Mark Underwood that there should be a Windows admin counterpart. See if you agree -- and add some of your own.

There seemed to be many voices in the choir singing a tune sounded by an archivist of Unix admin traits. Here's a humble return volley from the Windows corner.

No 1: Editor-free operations

We don't need no stinking editor. Scripting is fine, and we admire those folks proficient with vi and emacs, but we'd really rather not fuss with it. If we have to script, we have Powershell, but most of us are too busy exercising our other eight traits to learn it.

No 2: Elevated-privilege awareness

The fallout from Vista's evil public persona was that we became acutely aware of the pros and cons of both least-privilege and elevated-privilege operations. To paraphrase Churchill, never did so many suffer so much at the hands of a few. We're aware of it in our work, and acutely aware of the effects of indifference to it among our user communities.

No 3: Workstations count more than servers

Server technologies get the glamor and garner the big bucks, but it's managing service levels at the workstation that really counts. When the CFO's Outlook client hangs, we have responsibility for the whole supply chain, from his/her laptop F9 key, through all the switches and routers, and to his Exchange mailbox. Whatever the underlying issue may have been, the Windows admin learns to accept calling it "the Outlook problem" without whimpering.

No 4: Google Search, not code

In comparison to other types of admins, we don't risk inserting security breaches into our systems by writing specialized scripts, even if the affected task involves repetitive, manual tasks. Instead, we assume that someone somewhere has run into the same problem. We hop onto the nearest browser session and search for a fully-tested solution that has worked for someone else. Refer to Trait #1.

No 5: We prefer tested solutions

We try to stay off the bleeding edge. While we depend heavily on the world's largest software firms to vet what we deploy, time-tested solutions usually win out over the latest and greatest. When a user has something really cool to try out, we turn to a new VM on a separate subnet or DMZ.

No 6: Postmortems are for consultants

We're as geeky as the next geek, and marvel as much as the next geek over the elegance of a Stuxnet, but ultimately we're clannish, organization types. When there's a problem, we're as curious as anyone else about the causes - even if research shows that we made a mistake. But more typically, we're too busy dealing with the next rollout, the next crisis, or the next upgrade to dwell on it. We're well aware that a sober, balanced, best-practices postmortem is best accomplished by a disinterested third party than an overworked admin.

No 7: We know what we don't know

While we've dabbled with Red Hat and Ubuntu, and have worked hard to keep Linux machines happy in our server farm, we know there's a time to dabble, and there's a time to admit what we don't know. We're content to let other people maintain applications written completely in bash or csh, especially those with no man page.

No 8: We assume the problem is with whomever is asking the question - but keep it to ourselves

We can strut our expertise in server and network products like anyone else, but we're collaborators within a world of specialists. If we're CCNA's, we know better than to tell the Microsoft System Center Configuration Manager how she should be putting new VM's into her system or manage desktop licenses across her network. Similarly, we expect to field questions from the occasional user who happens to know as much as we do about a specialization, and we see that as a good thing; here's someone else to call upon when we need another pair of hands.

No 9: Network security is job two

Whether we are CISSP holders or not, we make it our business to know as much as possible about all facets of security measures the organization has in place. That includes everything from desktop disk encryption to apps and everything in between. We can't use the excuse that "Windows is usually the target of attacks" as a reason not to be aware.

*Bonus: Know when to hold ‘em, know when to fold (reboot) ‘em

It's true. Sometimes we have to reboot Windows. We wish we didn't have to. We'd rather be at home with our spouses, watching a game, or having a beer with friends. We do worry that the latest patches might destabilize things or create new breaches. We console ourselves by reminding ourselves that while the server is off, no one can break into it.

[*Editor's update: Updated the duplication of numbers in above list.]

About

Mark Underwood ("knowlengr") works for a small, agile R&D firm. He thinly spreads interests (network manageability, AI, BI, psychoacoustics, poetry, cognition, software quality, literary fiction, transparency) and activations (www.knowlengr.com) from...

54 comments
kathismom
kathismom

Where is ability to shut down and reboot repeatedly? That should be number 1. MSCE, sure I read the book and passed the test, I'm capable. Riiiiggght. A monkey could shut down and reboot. Unix ftw.

aaronangelle
aaronangelle

I read all of the comments and suggestion. I agree all of these and using these we can become ] beitcertified.

Cmd_Line_Dino
Cmd_Line_Dino

As ultimitloozer suggests Process Monitor is a good choice. One drawback is the volume of output it produces. It can be reduced by spending some time configuring its exclusion list. Or if you are facile with a good editor you can quickly exclude unrelated records from a large output. You don't mention how long a space issue event lasts. If it's on the order of a minute or more then I would do the following as a first approach. Create a script that every 20 seconds: 1) echo %date% %time% >> file 2) runs Sysinternals Pslist >> file 3) runs Sysinternals Du -q -l 1 [target] >> file Where [target] is either entire drive e.g. c:\ or a dir if the space problem is in a known dir e.g. c:\data The Pslist data will point to which program is getting CPU The Du data will show where the space usage is occurring. After an occurrence or two you can narrow the Du [target] When really close add to the script a 4) dir /a /s /od [target] >> file and perhaps comment out the Du I know from long experience that on any decently performing server such a script will have little detrimental impact on performance. edit: [target] was missing

michaelh.tek
michaelh.tek

If the first article was troll bait, someone got baited and felt they had to do some one-ups-manship. These lists have more in common than people are letting on. Win #3 "Workstations count more than servers" on this list, and Unix #8 "We know more about Windows than we'll ever let on" are obvious: At the end of the day both are still supporting users. Postmortems? Don't tell me that Windows admins don't do this because they have more important things to do. Oh gosh, the server blue screened, reboot it? No, they check the basics - check the logs, check the disk, and so forth. Just hoping for the best without troubleshooting is a recipe for disaster. "Prefer elegant solutions" gets the retort "Prefer tested solutions"? Are you serious? As if the Unix admin duct tapes everything with perl script while all Windows admins only use canned software? I've known plenty of Windows admins that spend inordinate amounts of time juggling VB code for their operations. Seriously, Unix admins can get along just fine without having to wrap everything in a bash or perl script. Plenty of Windows admins use text editors extensively, whether they are writing a clever SQL expression or manually checking a sprawling pile of XML output to find a problem... and even a Unix admin knows when a text editor isn't the right tool for the job. And last, don't tell me that Windows admins are ok with bouncing servers like yo-yos just because there's a problem and they don't have time to troubleshoot it. If you treat your PDCs like this you might want to brush up your text editor skills and update your resume soon.

ScarF
ScarF

And, just one more thing to add. As supports for our non-IT organisations, we are part of the solution having to deal with all the bugs and threats in the hardware and software worlds.

Here2serveu
Here2serveu

Windows admins are constantly under fire. Everything from outlook to terminal services requires reboots or tool that take for ever to run. If MS fixes this stuff we would be out of a job.

BlackKris
BlackKris

This list is something everyone in our profession should show to whomever they report to. Not only does it bring to light the subtle ways that we deal with the end user (be they co-workers or students) but also some of the "behind the scenes" acticities that we MUST keep up with just to keep "their Outlook accounts running smoothly" not to mention just being able to log on to hit the internet, access home directories, etc.

rwbilly
rwbilly

AMEN! Your preaching to the Choir. :)

jsneddon
jsneddon

With all of the new MS products including Powershell cmdlets as a directive, I think #1 is a bit short-sighted. Personally, I couldn't live without Powershell. I guess this is really an extension of #4: "Work smarter, not harder." Sometimes there are tasks that are specific to your organisation, which a Google search won't find, but if you have the knowledge to do it yourself, you are much better prepared IMO.

sbindlechner
sbindlechner

Let's face it - these days the veteran Windows Admin is just as focussed on improving their *nix skills as they are their scripts. Virtualization has completely blurred the line and a good admin delves into the hypervisor to understand the inner workings and how to influence them when the time comes. I for one am grateful for the patient Unix admin who took the time to give me a headstart and am the wiser for it.

theoctagon911
theoctagon911

Another trait I've found useful is that I try very hard to learn the entire network topology, regardless if I am responsible for it or not. This aides in troubleshooting tremendously. A good windows admin knows more than just windows. Jack of all trades, master of windows! Additionally, one solid motto that has helped through the years is: Path of least resistance.

ccie5000
ccie5000

This is really sad ... It's not the Windows admin's fault. They do an incredibly difficult job, often with great expertise, class and style. The fault is with the tools they're given. Microsoft has been borrowing ideas from Unix (and now Linux) for decades, and has usually changed them for the worse. The Windows filesystems are a case in point. Why are my hard disk, DVD, flash and network all on separate "drives"? Wouldn't life be easier if everything was presented to the user as a single, coherent filesystem? Windows admins rarely write scripts because Windows has never had a decent shell, much less good text-manipulation tools. And the only decent text editor Windows has ever had is vim. Maybe Powershell will fix the shell problem, but I'd rather use bash than learn another Microsoft-proprietary program. Is the Windows admin too busy fighting aligators to drain the swamp? Too busy rebooting (yet again), to prevent the next ten reboots? In my experience the best *are* interested in postmortems, to the extent they can prevent problem recurrence. Windows admins are great, God bless 'em. And I don't want their job any more than they want mine.

California Dead Head
California Dead Head

When it comes to having to keep 100's or 1,000 of users up and running it pays to be able to go to Google and find a KB article or other fix for your situation quickly and easily becuase 1,000's of other people have had the same problem. It can be like looking for a needle in a hay stack trying to find fixes and patches for Linux....wrote Scott Lagerbom.

Old Timer 8080
Old Timer 8080

Seems to be reflected in the behavior of many Windows Administrators. You have some good points and some extra tools, but the truth is that you need ALL the tools ( both in M$ and UNIX/LINUX environments ) to do a professional job. Your 'tude is why the UNIX/M$ war stays alive after decades... ( I've been on both sides of the UNIX/M$ admin job scene from working on Daytona to Unix S5R4 ) The extra ease of use for LINUX finally arrived with Ubuntu and the last couple of years. Now there is truly no difference between LINUX and Windows for the end user. Or the rest of the people going up the chain.

C33J4Y
C33J4Y

is it just me that is reading this wrong or.... But I still agree with everyword!

Psufan
Psufan

Great synopsis of a veteran Windows Admin! Couldn't have summarized it better myself being a vetaran of over 25 years. I might add that if you are a supervisor, train and delegate to subordinates based upon their strengths. Free yourself up to address more challenging issues which may require you to learn something new and expand your horizon.

tsadowski
tsadowski

I agree with the comment from nkhowland about scripting. The serious Windows Admin VETERAN who doesn't know his way around a batch script isn't either, a serious Windows Admin, or a veteran. Not everything can be accomplished in a GUI, and if I have to do the same thing more than twice, you better bet your boots that I will write a script to do it. I am over worked and I do NOT have time to click through two dozen screens over and over, when I can write a script to do it. And what VETERAN turns to only Powershell to get scripting done? Powershell has only been a viable option for a couple years, If I am scripting on windows I am probably doing with with a Batch/CMD script, yes sometimes PS or VBS/WSH come into play, but I am not comfortable in PS just yet. We are talking Veterans here, not the little wet behind the ears kids, who wouldn't know a command line if it bit them in the butt! If you are overworked try scripting your repetitive tasks, maybe you will have more time for the real problems!

nkhowland
nkhowland

I believe in reproducible results. I'm not interested in learning a unique solution to every problem. But scripts... how does a real administrator get anything done without them? "You just click on..." may be fine for some people but 4NT, KiXtart, batch files, PSTools, etc. are my best friends. When NT first arrived, I met some of the team and I asked them when the CLI tools from LANMAN were coming back. "Why would you want those?" they asked(!!!). The resource kits came out not to long after that.

imulo
imulo

How about our own built Knowlledge Base

gpachello
gpachello

I Agree ! To be honest, I would add this to trait No. 3: 1 - Microsoft Support 2 - Technet Forums 3 - Google Search

coppaj
coppaj

Most Window Admins are swifting going bald from all the headbanging and hair pulling!

SensibleSupport
SensibleSupport

It's why WIndows admins drink so much coffee. You've always to got to be ready to put out the next fire by p**sing on it. Just don't start me on: 1) Late night or weekend working 2) End users 3) End users (needs listing twice)

Vandy-SJ
Vandy-SJ

Experience gained in the trenches is a great teacher. All aspects of the computing environment, keyboard to firewall and everything inbetween, you end up owning and supporting. Well stated, Mark.

MaSysAdmin
MaSysAdmin

I read through the Unix admin list as well. It was a bit of an eye opener to see that Unix admins take opposite approaches to issues. I once had a coworker who had spent most of his career at IBM. When we would have a problem, he would spend days trying to figure out the cause rather than fixing the problem. It took me six months to train him that sometimes we cant fix the initial cause since the cause was probably some Microsoft developer! :-)

Slayer_
Slayer_

That describes it perfectly.

xultan
xultan

All those definitely apply to being a Windows Admin. We are responsible for the whole chain, from the "Server" being down to the network cable that the user kicked out with their feet.

contactasv
contactasv

It is truer that Unix administrators have a very tough job, and they do it very well, I have seen this a lot but there are some things that need to be clarified here: Windows Administrators also do a great job and we rarely write scripts because 1. we have tools that we can use to do the same thing or we know where we can find a good tested script and edit it to our needs. Has for Microsoft borrowing ideas from Unix and others, What is wrong in that? In today's world we are constantly influenced by the world around us and Microsoft is no exception. It might sound very strange to you but most of us find things easier with the Windows File System, and if we need a single place to search we just search the entire computer. The number of tools that are available to a Windows Admin is Hugh and growing, almost all of them help people to be more productive. Most Windows Administrators I know have a passion for taking a holistic view and supporting/learning things that help take I.T to the next level in the company. Last but not least do think about the fact that if Unix is the best and I am not denying that, how is it that in 40+ years of development/evolution it is unable to make solid inroads to the desktop segment? A good windows Administrator who is upto date on technology can actually spend time with family and friends as he/she does not need to worry about postmortems but only about the living. A healthy respect for all Operating Systems and their focus areas is a must for all Administrators from all platforms.

apotheon
apotheon

> Why are my hard disk, DVD, flash and network all on separate "drives"? Wouldn't life be easier if everything was presented to the user as a single, coherent filesystem? Despite all the polish and pretty colors on the face of MS Windows, you can't really get very far doing anything meaningful without the rusty steel girders showing through. Implementation details should not be visible by default, but in MS Windows they are a lot of the time. By the same token, when those implementation details are not visible by default, you should be able to get to choose to see those implementation details -- but MS Windows often gets that wrong, too. The same principles apply to programming languages. The Io language is interesting, and can be fun, but too many implementation details show through by default. The same is true of C, as in the case of pointer arithmetic. Meanwhile, VBScript does everything in its power to prevent the programmer from understanding why certain operations are horrifically in efficient, and to prevent the programmer from choosing another way; by contrast, the performance trade-offs between += and << are pretty obvious in Ruby. > Maybe Powershell will fix the shell problem, but I'd rather use bash than learn another Microsoft-proprietary program. 1. PowerShell lacks a lot of what you would expect from a powerful system command and scripting shell. In fact, its execution path management is by default atrocious, and it's designed for object-passing rather than text-passing operations (yes, really). 2. Don't use bash for scripting. Use sh. Portability matters. If you actually need the features of bash rather than the more limited feature set of sh, you should be using a "real" language (Perl, perhaps) anyway, and not a shell language. > Is the Windows admin too busy fighting aligators to drain the swamp? Too busy rebooting (yet again), to prevent the next ten reboots? In my experience the best *are* interested in postmortems, to the extent they can prevent problem recurrence. That's not entirely fair. MS Windows makes postmortems extremely difficult to conduct in any detail, thanks to its "you don't need to know that" design philosophy. As a result, it is often much more efficient to go through the same tedious motions to re-solve the same problem a dozen times than to discover the root cause the first time and ensure it never happens again -- if only because, sometimes, the design of the OS prohibits you from discovering the root cause or, if you find it, prohibits you from actually fixing it once and for all. Under those circumstances, the reasonable thing to do is often to just not worry about draining the swamp. If each reboot for a particular problem takes ten minutes from the moment you decide to reboot to the moment all services are running again, two hours total before the next time you upgrade the OS and the problems change is much more efficient than spending an hour figuring out the problem and discovering there's no way to fix it without violating the EULA -- following which you're going to have to reboot it anyway. edit: typo

CharlieSpencer
CharlieSpencer

"...you need ALL the tools ( both in M$ and UNIX/LINUX environments )..." Not if you're in a Windows-only shop. "Now there is truly no difference between LINUX and Windows for the end user." Except in the apps available to them.

Selena Frye
Selena Frye

Fixed the two #3s so now it's Nine + Bonus! Sorry -- I was scrambling at the end of the day yesterday. Didn't catch it!

knowlengr
knowlengr

That must be veteran Windows admin eye fatigue.

inouyde
inouyde

No, it's not just you

jstevens
jstevens

you hit that right on the head. What is funny is the PS commands that I am most comfortable with are dealing with Exchange - and that is becuase I am finding the Exchange management console to be clunky in comparison to using the PS commands. However for other repeditive tasks batch/cmd work a treat , same with VBS .. sort of like the saying in the old VHS/Betamax tape days - save time rewind ... scrippting has saved me plenty of time.

apotheon
apotheon

Maybe you don't qualify for true MS Windows administratorship. Have you considered a career as a Unix sysadmin? In my experience, MS Windows admins act almost phobic when it comes to scripting -- including me, before I got into Unixy work, despite the fact that I was eyeball deep in that stuff back in the day when DOS was what I had available to me. When I made the switch to Unix, a whole new world opened up to me. The problem, I think, is that MS Windows actually provides a hostile environment for admin scripting, and most MS Windows admins rationalize that away by acting like scripting is unnecessary. Well, I suppose it is technically unnecessary, as long as you prefer doing a lot of unnecessary, repetitive work, choosing to fight fires all the time rather than anticipate future fires and automate the solution before it's needed.

knowlengr
knowlengr

Would like to hear more about this for a future post - Mark

knowlengr
knowlengr

There's probably a whole syndrome of health ailments

CharlieSpencer
CharlieSpencer

If the problem has only occurred once, it may not be worth the time to determine the root cause. Reboot it, re-image it, reload it; whatever. And it's not my time that's all that important; it's the user's productivity that can't be sacrificed on the altar of troubleshooting.

poppaman2
poppaman2

As a Windows Admin, I too agree with the points on the list. As somewhat of a perfectionist, I also can identify with a Unix SysAdmin's desire to find the root cause and address it. The issue becomes one of time/resources: how much time can reasonably be spent determining the root cause of an issue before you say "The heck with it, lets address the symptom". Of course, if the problem is chronic, it then becomes most cost effective to resolve the underlying issue(s)....

apotheon
apotheon

> Last but not least do think about the fact that if Unix is the best and I am not denying that, how is it that in 40+ years of development/evolution it is unable to make solid inroads to the desktop segment? There are a number of reasons for this -- no single reason. Marketing is part of the reason. Fear of the unknown is another. Corporate partnerships is yet another. There's also the sunk cost fallacy working in favor of the current market dominator, as well as the preinstalled advantage. Certifications serve as advertising for the certified technology (and not so much for the certification holder, as many think). Then, of course, there's also the fact that people deploying systems would prefer something that feels like a one-click deployment over something stable, secure, and capable. There are dozens of reasons. It's not proof that MS Windows is great. > A good windows Administrator who is upto date on technology can actually spend time with family and friends as he/she does not need to worry about postmortems but only about the living. That's amusing. I was the netadmin for a defense contractor. 85% of the network was Unix-like systems (primarily Mandriva and RedHat at the time), and 65% of my time was spent fighting MS Windows fires, dealing with licensing (yes, we were one of a small percentage of the companies using MS Windows that took pains to be license compliant), and maintaining all the excess third-party BS that was needed to keep the MS Windows systems working properly. The Unix-like systems just ran themselves. Half of the time I spent dealing with the Unix-like systems was dealing with the problem of ensuring proprietary software the company used would actually run properly on those Unix-like systems -- so even in the relatively rare case of having to do any work with the Unix-like systems, half our problems were still proprietary software issues (mostly Maya for rendering servers). If it wasn't for the MS Windows issues, they probably would have only needed me part-time, so don't try to tell me a netadmin's life is easier with MS Windows.

Neon Samurai
Neon Samurai

I've a machine that keeps filling it's drive; doesn't crash out but triggers the monitoring software, sticks maxed out for a bit then finally clears itself out. I'd love to have a display of what files are being written when, how big they are and what space is available on the drive as they are written. spacemonger and a few other snapshot views won't do it. Even search and sort by create/mod date doesn't help. Maybe I can spot it by watching process monitor's graphs if I get a mouse-over at just the right place. Be intersted to hear if anyone knows of a utility that will tell me what files where written when with the affects on space and writting program included.

zenoscope
zenoscope

I'm surprised when people don't know about scripting. Coming from a (home) linux background and using DOS, I find scripting can be really useful. Is much more powerful and accessbile under linux, but can be just as useful under Windows, and there are tools from Linux ported to Windows, eg cygwin or indivudual tools such as wingrep. On the gui side, I'ev been known to script repetitive tasks with AutoIt.

daboochmeister
daboochmeister

My last project, we had a mix of 2/3 Linux, 1/3 Windows servers ... yet 2/3 of our time maintaining/fixing things was on the Windows servers. That's a 4:1 ratio per server, Windows:Linux. I just laugh when I hear people arguing that Windows saves money. (and yes, this was professional, experienced admins using good tools, on both the Windows and Linux sides).

Cmd_Line_Dino
Cmd_Line_Dino

As ultimitloozer suggests Process Monitor is a good choice. One drawback is the volume of output it produces. It can be reduced by spending some time configuring its exclusion list. Or if you are facile with a good editor you can quickly exclude unrelated records from a large output. You don't mention how long a space issue event lasts. If it's on the order of a minute or more then I would do the following as a first approach. Create a script that every 20 seconds: 1) echo %date% %time% >> file 2) runs Sysinternals Pslist >> file 3) runs Sysinternals Du -q -l 1 [target] >> file Where [target] is either entire drive e.g. c:\ or a dir if the space problem is in a known dir e.g. c:\data The Pslist data will point to which program is getting CPU The Du data will show where the space usage is occurring. After an occurrence or two you can narrow the Du [target] When really close add to the script a 4) dir /a /s /od [target] >> file and perhaps comment out the Du I know from long experience that on any decently performing server such a script will have little detrimental impact on performance. edit: [target] was missing

ultimitloozer
ultimitloozer

You can watch this type of information from the Sysinternals Process Monitor if you know when it starts happening. You can watch only the file activity you want and see its associated process. Don't know of anything that shows all of the information you are looking for with a single utility, but at least it will allow you to identify the culprit.

Editor's Picks