<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:series="http://unfoldingneurons.com/"
		>
<channel>
	<title>Comments on: A different network &#8211; Why administrators should avoid scripting</title>
	<atom:link href="http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/feed/" rel="self" type="application/rss+xml" />
	<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/</link>
	<description>For Windows Administrators</description>
	<lastBuildDate>Sun, 21 Mar 2010 23:51:58 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: WasF</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131973</link>
		<dc:creator>WasF</dc:creator>
		<pubDate>Sat, 01 Aug 2009 18:00:57 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131973</guid>
		<description>And how about the time you spend to master those mighty Admin suites? Is that not expensive?
And even when you do, there always are situations so specific that only an &quot;infinitely&quot; flexible tool (like scripting/programming) can handle. But then, scripting as I use it is only intended for that kind of situations.
I wouldn&#039;t hire an Windows Admin who doesn&#039;t talk DOS and VBS at least, but I certainly don&#039;t expect him to do his job using 1000+ spaghetti scripts. By all means, use a clean comprehensive point&amp;click solution for the main task, but don&#039;t tell me you&#039;re limited by it when a script can solve specific problems it can&#039;t.</description>
		<content:encoded><![CDATA[<p>And how about the time you spend to master those mighty Admin suites? Is that not expensive?<br />
And even when you do, there always are situations so specific that only an &#8220;infinitely&#8221; flexible tool (like scripting/programming) can handle. But then, scripting as I use it is only intended for that kind of situations.<br />
I wouldn&#8217;t hire an Windows Admin who doesn&#8217;t talk DOS and VBS at least, but I certainly don&#8217;t expect him to do his job using 1000+ spaghetti scripts. By all means, use a clean comprehensive point&amp;click solution for the main task, but don&#8217;t tell me you&#8217;re limited by it when a script can solve specific problems it can&#8217;t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carter Shanklin</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131676</link>
		<dc:creator>Carter Shanklin</dc:creator>
		<pubDate>Wed, 29 Jul 2009 01:35:22 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131676</guid>
		<description>I don&#039;t think the car analogy works. If I lifted my car&#039;s hood I wouldn&#039;t have any idea what I was looking at, I always take it to the shop. Then again, and here&#039;s the key thing, when I take it to the shop the mechanic doesn&#039;t need to ask me what I want the car to do, the outcome can be safely assumed. In fact no communication is needed except the price and how would I like to pay.

The situation in IT is very different. As someone who has been both developer and product manager, I know how difficult and time consuming it is to have one person to solve a problem that another person is facing. Not to mention the high failure rate. The reason is the difficulty of one person (the admin) giving another person (the developer) just enough information and expertise to solve the problem in the right way.

Admins encounter a lot of small problems, and when they do there is likely no off-the-shelf software to help, and handing the problem to internal development, or outsourcing it is expensive for the reasons noted above. We&#039;ve found with our PowerShell offering particularly that admins find huge value in the fact that they can be more self-sufficient. The interface is easy and powerful enough that they can solve the problem themselves rather than going through these challenges.

You raise a deeper question of whether this is a &quot;good thing&quot;. I view programming as a form of communication, it&#039;s communication between man and machine. It takes many years for people to learn to communicate with each other, but if you don&#039;t do it you end up functionally illiterate and basically useless to society. As computers continue to dominate more of our lives I feel that those who cannot &quot;communicate&quot; with computers are trending more and more toward functionally illiterate. So until computers can communicate with us in our natural languages, learning to &quot;communicate&quot; in some sort of machine language is time well spent.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t think the car analogy works. If I lifted my car&#8217;s hood I wouldn&#8217;t have any idea what I was looking at, I always take it to the shop. Then again, and here&#8217;s the key thing, when I take it to the shop the mechanic doesn&#8217;t need to ask me what I want the car to do, the outcome can be safely assumed. In fact no communication is needed except the price and how would I like to pay.</p>
<p>The situation in IT is very different. As someone who has been both developer and product manager, I know how difficult and time consuming it is to have one person to solve a problem that another person is facing. Not to mention the high failure rate. The reason is the difficulty of one person (the admin) giving another person (the developer) just enough information and expertise to solve the problem in the right way.</p>
<p>Admins encounter a lot of small problems, and when they do there is likely no off-the-shelf software to help, and handing the problem to internal development, or outsourcing it is expensive for the reasons noted above. We&#8217;ve found with our PowerShell offering particularly that admins find huge value in the fact that they can be more self-sufficient. The interface is easy and powerful enough that they can solve the problem themselves rather than going through these challenges.</p>
<p>You raise a deeper question of whether this is a &#8220;good thing&#8221;. I view programming as a form of communication, it&#8217;s communication between man and machine. It takes many years for people to learn to communicate with each other, but if you don&#8217;t do it you end up functionally illiterate and basically useless to society. As computers continue to dominate more of our lives I feel that those who cannot &#8220;communicate&#8221; with computers are trending more and more toward functionally illiterate. So until computers can communicate with us in our natural languages, learning to &#8220;communicate&#8221; in some sort of machine language is time well spent.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Daniele Muscetta</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131538</link>
		<dc:creator>Daniele Muscetta</dc:creator>
		<pubDate>Sun, 26 Jul 2009 07:34:41 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131538</guid>
		<description>Being a scripter myself, I don’t agree with one single word of what you say here. But that’s life… you can’t agree with anyone, I suppose ;-)
It is probably that I like scripting and CLI&#039;s so much.
And I am so happy that Powershell has been closing the gaps between those &quot;ITPro&quot; and &quot;Dev&quot; guys that always liked to stay apart from each other, rather than trying to understand what the other was actually doing and try to see the world from the other&#039;s perspective. In the Unix world there is no such a difference: sysadmins are programmers, and programmers are sysadmins too.
I don&#039;t agree that they have to be two disciplines. Staying apart from each other is what causes finger-pointing. It would be better to try to think out of the box and try to see the world in the other guy&#039;s shoes too.

Also, I am not saying that you must or should use the CLI everytime; IF there is a tool that does the job and can be leveraged, well - that&#039;s fine for me of course! But sometimes there is no such a tool, or often it is too big, or too expensive... or it is not exactly what you need... or maybe, as Jim says in one of the comments, maybe you also need to learn and customize the tool... 

In a number of cases, being able to &quot;roll your own&quot; is invaluable, IMHO.


Answer to Aszurom: have you tried LOGPARSER?</description>
		<content:encoded><![CDATA[<p>Being a scripter myself, I don’t agree with one single word of what you say here. But that’s life… you can’t agree with anyone, I suppose <img src='http://4sysops.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /><br />
It is probably that I like scripting and CLI&#8217;s so much.<br />
And I am so happy that Powershell has been closing the gaps between those &#8220;ITPro&#8221; and &#8220;Dev&#8221; guys that always liked to stay apart from each other, rather than trying to understand what the other was actually doing and try to see the world from the other&#8217;s perspective. In the Unix world there is no such a difference: sysadmins are programmers, and programmers are sysadmins too.<br />
I don&#8217;t agree that they have to be two disciplines. Staying apart from each other is what causes finger-pointing. It would be better to try to think out of the box and try to see the world in the other guy&#8217;s shoes too.</p>
<p>Also, I am not saying that you must or should use the CLI everytime; IF there is a tool that does the job and can be leveraged, well &#8211; that&#8217;s fine for me of course! But sometimes there is no such a tool, or often it is too big, or too expensive&#8230; or it is not exactly what you need&#8230; or maybe, as Jim says in one of the comments, maybe you also need to learn and customize the tool&#8230; </p>
<p>In a number of cases, being able to &#8220;roll your own&#8221; is invaluable, IMHO.</p>
<p>Answer to Aszurom: have you tried LOGPARSER?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Pietroforte</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131363</link>
		<dc:creator>Michael Pietroforte</dc:creator>
		<pubDate>Wed, 22 Jul 2009 19:50:44 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131363</guid>
		<description>I think I know for what you voted. ;-) The main point is that in most cases you save time if your work with GUI tools. Especially if you use a tool only every now and then, it simply costs too much time to check the manual again for the correct syntax. I discussed other disadvantages of the CLI in &lt;a href=&quot;http://4sysops.com/archives/why-powershell-servermanagercmd-and-co-don%E2%80%99t-really-rock-on-the-command-prompt/&quot; rel=&quot;nofollow&quot;&gt;this article&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I think I know for what you voted. <img src='http://4sysops.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  The main point is that in most cases you save time if your work with GUI tools. Especially if you use a tool only every now and then, it simply costs too much time to check the manual again for the correct syntax. I discussed other disadvantages of the CLI in <a href="http://4sysops.com/archives/why-powershell-servermanagercmd-and-co-don%E2%80%99t-really-rock-on-the-command-prompt/" rel="nofollow">this article</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bucky</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131362</link>
		<dc:creator>Bucky</dc:creator>
		<pubDate>Wed, 22 Jul 2009 18:55:43 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131362</guid>
		<description>Why the fixation on the interface? If a GUI or CLI tool meets the need what is the difference? Use the best available tool for the task at hand.</description>
		<content:encoded><![CDATA[<p>Why the fixation on the interface? If a GUI or CLI tool meets the need what is the difference? Use the best available tool for the task at hand.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Pietroforte</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131300</link>
		<dc:creator>Michael Pietroforte</dc:creator>
		<pubDate>Tue, 21 Jul 2009 20:43:54 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131300</guid>
		<description>Joel, you know me already well. Filling out answer files was yesterday. There are great GUI tools that allow you to create answer files. And who told you that you can&#039;t reuse a GUI tool? I&#039;ve never heard of one-way GUI tools. ;-) I&#039;d say a GUI tool that doesn&#039;t allow to save and load settings is just a bad GUI tool.

I&#039;ve studied physics and so I know that the situation is comparable. Those guys had to code a lot in former times but now it is not necessary anymore because most of the programs they need are already available. Re-inventing the wheel is never cost-effective. It is just a waste of time. This applies to all disciplines.</description>
		<content:encoded><![CDATA[<p>Joel, you know me already well. Filling out answer files was yesterday. There are great GUI tools that allow you to create answer files. And who told you that you can&#8217;t reuse a GUI tool? I&#8217;ve never heard of one-way GUI tools. <img src='http://4sysops.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  I&#8217;d say a GUI tool that doesn&#8217;t allow to save and load settings is just a bad GUI tool.</p>
<p>I&#8217;ve studied physics and so I know that the situation is comparable. Those guys had to code a lot in former times but now it is not necessary anymore because most of the programs they need are already available. Re-inventing the wheel is never cost-effective. It is just a waste of time. This applies to all disciplines.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel "Jaykul" Bennett</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131295</link>
		<dc:creator>Joel "Jaykul" Bennett</dc:creator>
		<pubDate>Tue, 21 Jul 2009 19:47:33 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131295</guid>
		<description>How on earth do you equate the computer skills of System Administrators with those of Physicists and Chemists? 

Don&#039;t you think that argument is a bit like saying that a long haul trucker shouldn&#039;t bother learning to change a tire or check his oil because physical science students don&#039;t need to.

Just because there&#039;s a GUI tool to do something doesn&#039;t mean that doing it by hand in a GUI tool every time is a better idea than writing a script you can reuse each time.  Next you&#039;ll be telling us that we shouldn&#039;t do unattended software installs because filling out an answers file requires special skills that are a &quot;waste of time&quot; to learn.</description>
		<content:encoded><![CDATA[<p>How on earth do you equate the computer skills of System Administrators with those of Physicists and Chemists? </p>
<p>Don&#8217;t you think that argument is a bit like saying that a long haul trucker shouldn&#8217;t bother learning to change a tire or check his oil because physical science students don&#8217;t need to.</p>
<p>Just because there&#8217;s a GUI tool to do something doesn&#8217;t mean that doing it by hand in a GUI tool every time is a better idea than writing a script you can reuse each time.  Next you&#8217;ll be telling us that we shouldn&#8217;t do unattended software installs because filling out an answers file requires special skills that are a &#8220;waste of time&#8221; to learn.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Pietroforte</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131219</link>
		<dc:creator>Michael Pietroforte</dc:creator>
		<pubDate>Mon, 20 Jul 2009 18:59:14 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131219</guid>
		<description>There are certainly cases when a problem has to be solved with a script. The question is if isn&#039;t cheaper if your company hires a professional programmer to write the program. You might also consider to change the application that produces non-standard log files that can&#039;t be parsed with standard log file analyzers.</description>
		<content:encoded><![CDATA[<p>There are certainly cases when a problem has to be solved with a script. The question is if isn&#8217;t cheaper if your company hires a professional programmer to write the program. You might also consider to change the application that produces non-standard log files that can&#8217;t be parsed with standard log file analyzers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Aszurom</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131204</link>
		<dc:creator>Aszurom</dc:creator>
		<pubDate>Mon, 20 Jul 2009 13:09:13 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131204</guid>
		<description>I think being a sysadmin who can code when I absolutely must, but of unfamiliarity such that it makes a simple script a drawn out excercise in Oreilly book digging, my lack of Powershell ability is a hinderance to me.  I&#039;m working to fix that.

Case in point... I have a big series of log files that no off-the-shelf tool is going to parse for me.  All I want to do is extract IP addresses and timestamps and export those into a .csv that I can then play with in Excel to spot trends.  If I were half as familiar with Powershell as I was once with Basica.exe and Turbo Pascal, it would be a done deal in 5 minutes.  As it is, I go without that info.</description>
		<content:encoded><![CDATA[<p>I think being a sysadmin who can code when I absolutely must, but of unfamiliarity such that it makes a simple script a drawn out excercise in Oreilly book digging, my lack of Powershell ability is a hinderance to me.  I&#8217;m working to fix that.</p>
<p>Case in point&#8230; I have a big series of log files that no off-the-shelf tool is going to parse for me.  All I want to do is extract IP addresses and timestamps and export those into a .csv that I can then play with in Excel to spot trends.  If I were half as familiar with Powershell as I was once with Basica.exe and Turbo Pascal, it would be a done deal in 5 minutes.  As it is, I go without that info.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Pietroforte</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131105</link>
		<dc:creator>Michael Pietroforte</dc:creator>
		<pubDate>Sat, 18 Jul 2009 20:21:53 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131105</guid>
		<description>I think the fact that most Windows management tools are designed to do more than a single task is one of their biggest advantages because this keeps the number of tools you need down. In large environments you usually have sophisticated systems management solutions that allow your to configure every bit on all your machines without writing a single line of code. I remember quite well that at my last employer we had quite a few scripts which have been written by different people over the years. Some of them left the organizations and nobody really knew how those scripts work. Modifying a script that has been written by someone else is usually a time consuming task. The real costs of a script often only become apparent years after it has been written. I hope they never run into problems with one of my scripts because I am sure it is mostly spaghetti code since I am not a professional developer. Thus I think the support problem you mentioned applies mostly to do-it-yourself automation tools and not to professional management solutions.</description>
		<content:encoded><![CDATA[<p>I think the fact that most Windows management tools are designed to do more than a single task is one of their biggest advantages because this keeps the number of tools you need down. In large environments you usually have sophisticated systems management solutions that allow your to configure every bit on all your machines without writing a single line of code. I remember quite well that at my last employer we had quite a few scripts which have been written by different people over the years. Some of them left the organizations and nobody really knew how those scripts work. Modifying a script that has been written by someone else is usually a time consuming task. The real costs of a script often only become apparent years after it has been written. I hope they never run into problems with one of my scripts because I am sure it is mostly spaghetti code since I am not a professional developer. Thus I think the support problem you mentioned applies mostly to do-it-yourself automation tools and not to professional management solutions.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Joel</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131095</link>
		<dc:creator>Joel</dc:creator>
		<pubDate>Sat, 18 Jul 2009 16:01:51 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131095</guid>
		<description>Scripting skills are popular and pretty much a requirement in the *nix world often because it is the only option. A valid argument is that most Windows automation can be accomplished using free software tool available on the web. However I would like to point out that many of these tools are not very well supported - if at all, and are often designed to do much more than the single task you are trying to accomplish. When you consider the sum of such tools introduced into a large environment, the complexity and redundancy of purpose they introduce would eventually become overwhelming, whereas single-task scripts using a preset standard would make supporting the environment much more cost effective.</description>
		<content:encoded><![CDATA[<p>Scripting skills are popular and pretty much a requirement in the *nix world often because it is the only option. A valid argument is that most Windows automation can be accomplished using free software tool available on the web. However I would like to point out that many of these tools are not very well supported &#8211; if at all, and are often designed to do much more than the single task you are trying to accomplish. When you consider the sum of such tools introduced into a large environment, the complexity and redundancy of purpose they introduce would eventually become overwhelming, whereas single-task scripts using a preset standard would make supporting the environment much more cost effective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael Pietroforte</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131093</link>
		<dc:creator>Michael Pietroforte</dc:creator>
		<pubDate>Sat, 18 Jul 2009 14:50:29 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131093</guid>
		<description>You have some good points. However, I think that you misunderstood the core of the argument which is probably due the fact that I didn&#039;t explain it well. It is not that I recommend that every time you have to solve an &quot;automation problem&quot; you should fire up your browser to find an appropriate tool.

My point rather is that there are very sophisticated management suites that solve all kinds of automation problems. That is, once you filled your toolbox with the GUI tools that fit to your environment,  there will be no additional tweaking or learning. However, if you have to write a new script every time you come across an automation problem, it will cost your company more than just the $150 because it will sum up over time. I think we agree that a script that you hacked together in two hours only solves a very specific problem. But a $30.000 management suite can do little more than your tiny script. And don&#039;t say that your company only paid once for the script but you can use it forever. You have to adapt the script every time your environment changes which costs additional money. You also forgot to mention that it costs you a considerable amount of time to keep yourself up-to-date with the latest scripting technology which probably is the biggest cost factor for your company.

Only since I started blogging I realized how many great admin tools are out there, some are free and some cost money. I found that most of them are worth their money. Otherwise these companies wouldn&#039;t survive. Do-it-yourself is fun - yes - but only  in rare cases cost-effective. Another word for this development is &quot;industrialization&quot;. It appears that IT management is now mature enough to become industrialized. However, I agree that there are still many networks in the wild that are not standardized enough to be ready for this step. Thus for many admins scripting is still a part of their daily work.</description>
		<content:encoded><![CDATA[<p>You have some good points. However, I think that you misunderstood the core of the argument which is probably due the fact that I didn&#8217;t explain it well. It is not that I recommend that every time you have to solve an &#8220;automation problem&#8221; you should fire up your browser to find an appropriate tool.</p>
<p>My point rather is that there are very sophisticated management suites that solve all kinds of automation problems. That is, once you filled your toolbox with the GUI tools that fit to your environment,  there will be no additional tweaking or learning. However, if you have to write a new script every time you come across an automation problem, it will cost your company more than just the $150 because it will sum up over time. I think we agree that a script that you hacked together in two hours only solves a very specific problem. But a $30.000 management suite can do little more than your tiny script. And don&#8217;t say that your company only paid once for the script but you can use it forever. You have to adapt the script every time your environment changes which costs additional money. You also forgot to mention that it costs you a considerable amount of time to keep yourself up-to-date with the latest scripting technology which probably is the biggest cost factor for your company.</p>
<p>Only since I started blogging I realized how many great admin tools are out there, some are free and some cost money. I found that most of them are worth their money. Otherwise these companies wouldn&#8217;t survive. Do-it-yourself is fun &#8211; yes &#8211; but only  in rare cases cost-effective. Another word for this development is &#8220;industrialization&#8221;. It appears that IT management is now mature enough to become industrialized. However, I agree that there are still many networks in the wild that are not standardized enough to be ready for this step. Thus for many admins scripting is still a part of their daily work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim</title>
		<link>http://4sysops.com/archives/a-different-network-why-administrators-should-avoid-scripting/comment-page-1/#comment-131090</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Sat, 18 Jul 2009 12:25:21 +0000</pubDate>
		<guid isPermaLink="false">http://4sysops.com/?p=3150#comment-131090</guid>
		<description>So far off course that I can&#039;t even figure out where it came from.

I&#039;ve been a systems administrator for 20 years on too many platforms to keep track of, and on each platform I honed my scripting skills to the point that I could build a safe and robust script to accomplish the specified task without excessive time being required.

When you talk about downloading a tool being more cost effective than scripting, you must be talking about very small environments.  For example, my time costs the company about $75/hr.  If I take a couple of hours to script a tool, that&#039;s $150.  If I can buy a tool for $50 that does the same thing but has to be licensed on 650 systems, that sets the company back $32,500.  Which do you think would be an easier sell?

Yes, there are times with a comprehensive tool can be downloaded, but to make a generic statement that it&#039;s not efficient for system admins to code or script (there is a difference), is not accurate.  Even if you can download a free tool that seems like it does what you are looking for, there are invariably tweaks that have to be done to fit your environment so you still have to have the skills to modify the tool somehow.</description>
		<content:encoded><![CDATA[<p>So far off course that I can&#8217;t even figure out where it came from.</p>
<p>I&#8217;ve been a systems administrator for 20 years on too many platforms to keep track of, and on each platform I honed my scripting skills to the point that I could build a safe and robust script to accomplish the specified task without excessive time being required.</p>
<p>When you talk about downloading a tool being more cost effective than scripting, you must be talking about very small environments.  For example, my time costs the company about $75/hr.  If I take a couple of hours to script a tool, that&#8217;s $150.  If I can buy a tool for $50 that does the same thing but has to be licensed on 650 systems, that sets the company back $32,500.  Which do you think would be an easier sell?</p>
<p>Yes, there are times with a comprehensive tool can be downloaded, but to make a generic statement that it&#8217;s not efficient for system admins to code or script (there is a difference), is not accurate.  Even if you can download a free tool that seems like it does what you are looking for, there are invariably tweaks that have to be done to fit your environment so you still have to have the skills to modify the tool somehow.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
