If you’ve been to the SAPIEN blog in the last few days, hopefully you’ve noticed the simple poll: “Are you using PowerShell in a production environment?” Right now 75% of respondents are using PowerShell today to manage their network. I’m curious about the other 25%. I’m not passing judgement but am genuinely interested why an organization is NOT using PowerShell. Here are some reasons I can think of and I expect there others I haven’t considered:
- We don’t see PowerShell’s value or have nothing to manage that requires it.
- We don’t have the training or experience to deploy it.
- It’s coming, but is a low priority.
- Management doesn’t recognize/understand/appreciate PowerShell.
- We’re waiting for PowerShell v2.0.
Are these the reasons for the other 25%? Or what else is holding back adoption? I’m sincerely interested. Oh, and if you haven’t voted yet, please do. Thanks.
I’m using powershell all over the place in production. It rocks!
For the most part, me and my co workers have allot of experience with VBScript. Mostly we write scripts to speed up management stuff, and as many IT pros, we are always in a hurry. So when we are again in a stressful situation where we can’t afford to lose time messing around with something we don’t (yet) understand, it’s very tempting to just write another VBScript to fix the problem, because that’s what we know and can produce fast.
I have a Powershell book ready to be used, but I haven’t come around to study it. In the near future I will probably start to use powershell bit by bit, to see if it makes life easier.
A typical Catch-22. You can’t get the time to get up to speed on PowerShell, yet I know you would find it more efficient than VBScript once you have a little proficiency. I think you’ll eventually find tasks that took 20 lines of VBScript can be executed in PowerShell with a one line command.
Believe it or not, in our environment, .NET 2.0 is not a standard and is still in the “testing” phase. So we can’t install it on our machines. I believe it’s a prerequisite to installing PowerShell, if I’m not mistaken.
Yep, .NET Framework 2.0 or later is required. I hadn’t even considered that as a possibility, especially now that the Framework is up to v3.5.
1) The script engine is installed everywhere. Powershell isn’t, never mind the .Net framework issue.
2) The pile of VBscripts I have to hand is easier to build on – edit an old script to fit the new job – than write PS from scratch.
3) Similar to Richard W: My productivity in powershell is still very low. Yes it takes three lines to of PS to do what 60 lines of VBS does, but it takes longer to work out what those three lines should be than to write the 60…
4) FUD: will the arrival of PS2 break PS1 scripts – why risk writing production scripts with a new version justaround the corner…
Last, and least I hope:
5) C-ish structure – bleuch. 😉
Your concerns are genuine. So I take it you voted No.
Remember that you only need to install PowerShell where you want to use it interactively or run a PowerShell script. If you can remotely manage a server via WMI or other technologies like ADSI, you only need PowerShell on your desktop. This will change in PowerShell v2.0 (but don’t expect to see that anytime soon). And the new version should not break your existing scripts.
No doubt there is a learning curve to PowerShell, but you had one for VBScript as well.
I’m not trying to persuade you to drop everything for PowerShell, merely trying to raise some discussion points.
I am actually a developer, so I don’t touch production. I have a vested interest in getting the people that do to use powershell, however, so I am interested in this problem.
The reasons we don’t use powershell in production:
* Lack of knowledge – few of our admins know anything about production. We even outsource most of our IT admin work and the company that we outsource to doesn’t even have Powershell knowledge.
* Installation – our production environment is still Win 23k. As someone else mentioned above, the scripting runtime is installed everywhere, but not powershell. There is huge resistance to installing anything in our production environment.
I would love to have powershell in production because it would make it easier for our whole business to administer our environment _and_ custom .net line of business applications. I use powershell in development and testing alot for automating my applications, boring database maintenance tasks, etc. I would love to just be able to give our admins a script or snapin and have them be able to do all that without me having to walk them through things pointy-clicky over the phone or a word document.
Oops: s/few of our admins know anything about production./few of our admins know anything about _powershell_./
Version 2 will not break any version 1 scripts. As VBScript convert I understand everything mentioned above, but I would just add. That I agree with Jeffery, if you’re running the script at the user/workstation use vbscript. If your managing your environment, meaning running the script on your system. You really need to use PowerShell. COM is slowly dieing, and vbscript will be a derogated language, posh IS the future. So unless you plan on retiring in the next 2-3 years….
The learning curve is nothing compared to vbscript. All it really takes is kicking off the training wheels. How?
Solve your NEXT fire with posh. Under a timeline, head over to scriptinganswers.com or powershellcommunity.org… lot of smart people who love to help.
“PowerShell is just fun to use, something vbScript never was”
-sepeck on #powershell
my 2c
Glenn
Richard W put it well already, but essentically PS is more cumbersome to get used to, but more importantly is that it is simply not pervasive enough yet. It requires more effort to deploy into a large enterprise environment becuase you have to push out .NET and PS runtimes to everything or you end up with a mixed environment. WSH is already everywhere so we can count on it and it’s easier to write code because it’s a more basic “scripting” language. PS is really more like a semi-programming language than a scripting language. The power is obvious but the trade-off is complexity, reach and time.
What Jeffrey said… I’m in the Catch-22. The refinements on my scenario are that we have only installed .NET on servers where required (as we implement W2K3 and W2K7 this issue is going away), and that my language of choice has been batch, augmented with Win32 GNU tools and the PS Tools from SysInternals (now Microsoft).
I totally agree about how difficult it can be today to deploy PowerShell and it is certainly not the right tool for all jobs. But as i said earlier, you only need to deploy it where you are going to run scripts or want to use it interactively. Also be sure you don’t think of PowerShell has merely a scripting language. It is also a powerful interactive management shell. The fact that you can automate a PowerShell session into a script is icing.
Andrew, if you are already batch/cli oriented then you will love PowerShell once you can get your hands on it.
We are planning to begin using in our Windows 2008 server ventures, but for now the overhead of migrating to ps would not be cost effective.
As I see it here are my pros and cons of powershell.
Pros
1. Free!
2. Consistency
3. Expanded feature set
4. Improvement upon WSH
5. .NET integration
6. Export operations to PS code from applications (like exchange and sccm)
7. Flexibility as scripting or shell.
Cons
1. Terrible native tools. I’ve already purchased commerical admin scripting tools that still are better than vbs or powershell. What is the value add of buying (and not saying bad) a commercial tool like Sapien to replace what already works for me.
2.Hideous language syntax for admins. Moving from a procedural command driven mindset to a more object oriented and verb noun . notation is confusing. C# style was probably not the best idea. Python might’ve worked better (IronPython anyone?)
3. Lacks maturity at this time. This includes things like integrated libraries for easier functions. There are other products which do this rather nicely and integrate them to make the whole package easy. CMDLets are nice, but what value add does give me over functions from includes? None really. Third party offerings are nice, but when core functionality is still missing from the native package and the integration is lacking I tend to cringe.
4.Requires deployment. Would be nice if they could be complied with a mini byte-code runtime embeded into the script until PS becomes a standard in Windows.
5.This is more of a gripe, but there are far too many powershell resources out there and none of them reall consolidate everything I’d want into a single website.
6.Help files really need help. I’m used to higher quality help files, so perhaps I am biased here. Better examples and descriptions!!!
All in all it’s a murky offering. I see it’s potential as it matures, but I’ll stick with what works where I can and use it only when forced.
One of the things that put me off was the threat of v2 and the big changes between the two. I’ve been using C# since .Net 1.1 and it’s grown a lot – I’m still not familiar with all of the 2.0 stuff, let alone, 3.0, 3.5 and 3.5 SP1 – I think the C# team have acknowledged that they’re developing it too quickly for commercial programmers to keep up – we have to justify time spent on training in terms of return. Before I even got started with PoSh v1, I knew v2 was coming and there would be big changes.
Another is that I know both VBScript and C#, and PowerShell is very different from both so yet another paradigm to be learnt. From where I am, it looks like the north face of the Eiger – horribly and frighteningly steep. None of the introductory material has really coped with that, to me.
The final difference was is the abysmal support for AD. Dropping into native .NET is just unnacceptable. Frankly, the native .NET stuff from C# is rubbish – I’d written my own helper classes to make it nicer. If PowerShell had done AD properly, I’d probably have persevered with it because most of my scripts are used to manipulate AD. We have SMS to manage machines and software, Ops Manager to manage the operational side but we don’t have anything for AD.
There is AD support coming from Microsoft for PowerShell, although it will require Windows 7 and Server 2008 R2. Although the free Quest Powershell cmdlets are an excellent alternative and work with what you have today.
We don’t use powershell because we have a lot of win2k servers working in our infraestructure and powershell is not compatible with it.
At end with vbscript and .cmd scripts are enought for our requeriments now.
sorry for my terrible english.
I’m the only member of our IT Staff currently who is using it in Production. None of the others worldwide in the corporation are even using it for testing purposes.
Essentially this is because of the security issues with regards to codesigning on a Windows2000 domain and a lack of understanding by the IT management of the necessity for preparing for the use of a technology before it comes “installed by default”.
Personally I’m still learning it, but I spend as much time in it as I can on a daily basis and am using (and I must say loving) the new Remoting tools…