Is Powershell a mature enough tech for enterprise to be using?
Are its many benefits worth the time and effort to convert existing VBS scripts, or would you only use it for new scripting projects?
We are currently using a mixture of vbs and batch files, with a login script as opposed to alot of GPO.
We don't have a huge number of .NET programmers, whereas just about everyone at least knows a bit of VB.
“Mature enough” is slightly subjective and depends on what you mean exactly.
1) Is it powerful enough to get the job done? -- Yes. But it is not the best tool for all the jobs; think, choose.
2) Is it bugs/issues free? -- No. To be prepared and informed you may want to take a look at some most voted bugs/issues in here:
https://connect.microsoft.com/PowerShell/Feedback
3) Is it easy to learn? -- It depends; basically I think it is not easy for not professional programmers. But it is definitely possible, step by step, having fun:
http://blogs.msdn.com/b/powershell/archive/2010/03/09/falling-is-learning-just-focus-on-having-fun.aspx
It’s a good idea to start using PowerShell for new tools. As for the old tools (e.g. VB), I would not convert them into PowerShell unless there are good reasons. In most cases they can be perfectly called from new PowerShell tools.
Yes. PowerShell brings into one environment the power of .NET, COM, WMI, and more. I use it every day to administer a family of 30-or-more servers, and it has proved to be both stable and productive.
I think PowerShell is a powerful thing. Microsoft is going into the "administer everything from powershell" direction (MS Exchange management shell, SharePoint 2010 management shell). This makes me think that this scripting technology will not die soon. Another thing - since the administration scripts are written in PowerShell, you can learn a lot from them, and hence gain more automation of your administrative tasks.
Convert only when needed
Prefer PowerShell for new work
It is enterprise ready and there are gotchas as with anything
Doing work in PowerShell now improves your skill
Doing work in PowerShell now positions for vNext products enabled with PowerShell. Big win.
Related
Question
What would be a good (ideally, technical) reason to ever program some non-trivial task in dos batch language on a modern Windows system as opposed to downloading either PowerShell, or ActiveState Perl?
To be more specific, I make the following two assumptions for the duration of this question:
anyone technical enough to be able to write a medium-complexity batch script is technical enough to install either of the scripting interpreters.
Neither of those two present enough of a learning curve for basic batch replacement tasks that said curve would outweigh the pain of doing any remotely-non-trivial task in batch.
Notes
"You need a batch program for autoexec.bat" is not a valid reason. Your autoexec.bat may consist of simply calling non-batch script.
If you disagree with either of my 2 assumptions above, that's fine, and I may be wrong. But my question is specifically "assuming those 2 assumptions are correct, what would be the reason to still stick with batch?" If it makes it easier to suspend disbelief (in case you disagree with me), add in a 3rd assumption that the question is limited to people who already posess at least some modicum of PowerShell or Perl experience.
To re-iterate - this is not meant to be a subjective question about how easy it is to learn PSh or ASPerl compared to doing advanced batch coding. That is a separate question that is too subjective to be bothered with in this post.
Background:
I used to do some fairly complicated batch programming back in the elder days, and remember batch as one of the worst possible programming languages I had encountered.
The idea for this question came after seeing a bunch of batch questions on SO, and trying to grok the answer of one of them out of sheer curiosity and giving up in pain after a minute, exclaiming mentally "why would anyone go through this pain instead of doing that in 1 line of Perl?" :)
My own plausible answer
I assume there may be an an likely DOS-compatible system, which has DOS interpreter but has no compatible PowerShell or Perl... I'm not aware of one but not completely impossible.
Typically, the rationale is that you need the script to run on a machine which does not have another interpreter and on which you are not allowed to install an interpreter. Production servers in many companies are a good example -- you want them to have as few exploitation vectors as possible, which means no scripting languages that are not required for application functionality.
You're right when you say that the batch language is a terrible language -- there's a reason they sunk the time and money into building PowerShell -- but it's also the only universal language you can rely on across the myriad versions of Windows.
Because I work at a bank where the default browser is IE6 on Windows XP and I have no idea if I'll be able to install PowerShell on someone's computer and I have a batch file which they can use to quickly and easily:
sqlcmd with some pre-import SQL
bcp
sqlcmd with some post-import SQL
With the whole batch needing to be RUNAS /NETONLY because the workstation does not participate in the domain that the SQL Server is on/trusts.
Not that I'm complaining or anything...
And I would say they are non-trivial because sometimes they take parameters and they require some pretty crazy escape quoting.
I have a contract at a major utility company which absolutely does not allow unapproved programs on their computers. That would be expected of computers attached to the innermost networks which connect between control computers and devices, but the ban applies to the general purpose and administrative networks too.
The approved operating system is Windows XP SP3 with IE6. Upgrading is not allowed until technical support blesses it. Which, it seems, still may be some years from now.
Therefore, batch files are the only general scripting tool available. Some developer machines have access to C++ compilers, but the resulting programs are not permitted for internal distribution until the conclusion of a (probable multi-year) validation effort.
You could also choose to use vbscript or jscript rather than perl and you wouldn't need to worry about installing any additional software.
various reasons
Its company policy, be it for security or other illogical reasons given by management, that you strictly
use DOS.
You had to support some legacy DOS
scripts already written.
You or the admins in the company
only know DOS and have no capacity
to learn other languages.
You are coding for part of a larger
DOS program already written
Doing things the "harder" way make you look
cool.
You have a lot of time on your hands
to devise workarounds for some
things that are difficult to do
easily with DOS
I've been around Visual Basic for years in high school, and I've grown up with the IDE supplied by Microsoft. It'd wonderful, but the educational and "working-model" editions of VB available to me through school don't allow me to redistribute software, as part of the EULA with Microsoft.
I instead find myself working in perl to design programs for friends and family, and it works fairly well, but I don't have a firm grasp on building user interfaces yet. I understand I could design user-interfaces with tcl/tk for perl, but the notion of coding all of that by hand is a bit daunting to me. That brings me to my question.
Do you have any suggestions for a tool I could use that would allow me to build GUIs for my perl programs?
Thanks in advance!
In addition to what tsee suggested, you can have a look at :
Perl/Qt (using Qtdesigner) and Perl::GladeXML (using Glade)
With Glade and Qtdesigner, you can generate a XML file that will describe your user interface and it will be a matter of hooking your perl code to widget's events.
I don't think you will find something as simple and well integrated for Perl as the Visual Basic GUI builder. A couple of pointers:
wxGlade can be used to design GUIs for the Wx GUI toolkit (for Perl, not only Python).
For Win32::GUI, you can use the GUI Loft to achieve something similar.
I think there's a bunch of other GUI builders including at least one for Tk, but I don't remember the name.
Either way, I believe you will have to accept that you have to do more coding vs. designing when compared to VB. The upside is that if you use Tk or Wx, your programs may well be portable to all major operating systems.
For a Perl-specific development environment, you might want to check out Padre, which is itself written in Perl using Wx. It's under active development, so eventually, somebody will probably integrate a GUI builder, too.
Frankly, having thought about GUIs for years and never getting round to them, I've found the best way to distribute GUI apps with perl is to use Catalyst, its built in server and for windows users, distributing it with Strawberry Perl (the professional edition comes with Catalyst included). For Linux or Mac users a local::lib installation to pull in the required cpan modules. Optionally bundle in a copy of portable firefox if you want not to have the usual web development pain caused by internet explorer.
tl;dr; Sidestep the whole issue by going for web development with a framework that comes with its own standalone server.
Are there any technical benefits to Windows/Microsoft as a platform to use while developing, over a Unix dialect such as Linux or Solaris?
I know that companies choose Microsoft at times because there's simply not enough programmers available that know Unix, or that these programmers are much more expensive to hire.
So assuming all developers knew Unix and Microsoft equally well, would there still be cases where you are better off developing in Windows?
To me there's only two arguments for using Windows as a dev platform:
You have to because you're doing .Net/Windows development (or because the company simply gives you no choice); or
The apps, specifically Microsoft Office/Exchange. I'm sorry but OpenOffice is dreadful in comparison to Word/Excel.
Apart from that imho Linux has every other advantage including:
MUCH faster filesystem (particularly important when dealing with lots of small files). Last year I went from a build time of 8-10 minutes to 2-3 just by this switch (ant build of same code base);
Typically your dev environment then matches your production environment (if you're production environment is Windows your dev environment will be Windows almost guaranteed), which can be useful. We've had issues with Java classpath visibility because of differences between JBoss on Windows and Linux; and
A much better set of command line tools (yes I knwo you can use Cygwin, etc but it's not as good).
That's one reason why I find the idea of a Mac as my next dev workstation so appealling: you can look it as either Unix with applications (ie Office) or Windows with a decent filesystem (will be even better if/when OSX adopts ZFS), either way it's a win. The only thing that's really put me off is that Apple does stupid things like delay Java 6 release by a year just so they can put the Leopard Look and Feel in.
Just off the top of my mind:
.NET (even though mono is really great)
Visual Studio - probably the best IDE around
Excellent documentation (The MSDN Library is way much more developer friendly than man pages in my opinion)
Huge userbase (that's more like a business thing but still it is a very important factor)
Binary compatability (it's much easier to support 4-5 kernels and standard C library versions than the infinite number of combinations you can find in Linux distros)
One of the best things you can do is keep your options open. Chopse a platform independant technology and you'll be able to have software for any O/S or implementation. From a technical standpoint, this makes a lot of sense as well as from a business one.
As for specific technical advantages to the Windows platform, other than the large developer community and development information store and widely supported IDE's like Visual Studio, I'd say you'll be hard pressed to find one. Even there, Eclipse can do just as good a job with a platform independant technology.
Microsoft systems tend to have much better integration between different parts - there's a lot less heterogeneity to worry about if you're using binary-only software (x86 and comctl3d is a lot easier to support than everything *nix runs on).
The learning curve on Windows is shallow to begin with but has a longer overall distance. On Unix/Linux the beginning is a struggle but getting stuff done becomes easier later on, when the inner workings of the OS begin to make sense.
At least that's been my experience with them. Windows for quick payoff, Linux if you're going to be doing something much longer-term. And virtual machines if you can't decide :)
I think this question presents a false dichotomy. There's no reason you have to choose windows over unix or vice versa. Virtualization is free and easy. It's the best of both worlds!
One reason we have Windows development platforms (even though our production is on Linux or Solaris) is common environment for all.
That means all the different populations involved in the realization of a softwares:
are not all developers (business, functional people are also concerned with a working environment)
are all on the same platform (Windows)
use all the same tools to write/communicate (as in Word, PowerPoint)
can have their same environment on laptop
In short: uniformity of environment for all (developers and non-developers alike).
The other reason is depreciation: it is easy to manage depreciation for PCs, where the services are lighter than a full-scale Unix server (like a Sun Fire, a F15K or F50K, ...): the latter needs some expensive assistance service contracts (like "bronze", "silver" or "gold" depending on the level needed). A PC is easier to fix/replace, and is not as critical is a developer "mess up" on it and crash it utterly ;)
That being said, the downside of this is you do not change PC every day: it means managing a large parc of desktops, you cannot just decide to upgrade like that (and that goes for Os too).
So where the other answers are all about "virtual machine" whereas your set of PCs is from 2003, with only 40Go of hard-drive and 1, may be 2Go of memory..., you realize "virtualization" is not always an obvious solution.
Hence, some Unix "integration" server are required for developers to test their products in an environment closer to the target. In a way, this is better, since those integration servers are managed in a uniformed way, avoiding the syndrome of "it works for meTM", as opposed to virtual machine, where each developer is the own root/administrator of one's own little world/server ;).
I can give you a common arguments that Windows folks might make, though not one I necessarily agree with.
People sometimes think that Windows boxes at production time are easier to maintain and deploy. That is because there are a lot of visual tools available to the admin. Therefore they prefer .Net or a Windows-specific development language for easy integration.
If your customers or internal clients use all windows desktop computers, some would argue that its less legwork to do stuff with Windows servers. This includes stuff for Microsoft Office document sharing (i.e. sharepoint) or stuff with Windows File Sharing. Obviously its easier to write a .Net application to deal with such Microsoft-specific constraints.
I can't really think of any other reasons. The latter one is probably the most valid -- there just might be some microsoft-specific technology that is hard to integrate with unless you use MSFT development tools.
Peripheral reasons for some specific kinds of development:
you need to see how things look in both firefox and explorer
you're working with flash (which AFAIK you can't develop on linux, and the players are terrible).
you're working on a project that involved MS office integration
you're office has some godawful mail or notes system that you can't log into any other way. ditto for some vpn setups.
I consider all of these things to be regrettable.
Why not use both?
In either scenario, you could use a virtual machine in either Windows or Linux/Unix for basically nothing using Virtual Box or Vmware player. Or you could remote desktop/vnc to the other platform from your development box. If you develop in .net you would probably be better off on Windows for dev. If you develop for LAMP, either Windows/*nix would be fine.
give me apache mysql (ok postgres in a pinch) php and eclipse .. who cares about the OS ..
I package our server releases into zip files using a batch file (Windows), running the command-line version of WinZip. Previously we did this sort of thing "by hand" but I developed the process of automating it with a batch file.
The batch file has become quite complicated because our product is complicated (i.e., Which sections are we releasing this time? Are we releasing the config files as well?) and I'm starting to run into some frustrating limitations with batch files.
Would PowerShell be a good thing to investigate as an "upgrade" to the batch file? Or is that complete overkill given that most of what it would be doing is firing off DOS commands?
Bonus: can PowerShell consume .NET assemblies? As in, could I start doing the zipping with SharpZip?
If you have a working solution, then you don't need to go to powershell. Having said that, if you plan to make changes or improve the process then I would highly recommend powershell as the way to go. Powershell can access .Net assemblies...mostly. Some assemblies are structured in a way that makes it more difficult than others.
You can check here for some resources if you decide to look at powershell.
Initially I was really excited about PowerShell. Finally a powerful native shell on Windows. However, I quickly realized that compared to your favorite unix shell PowerShell is just way too verbose. Even doing simple stuff takes way too much typing compared to what you can do with bash and GNU tools for Win32.
I like the idea, that the shell knows about different types, but if I need to do that much additional work, I prefer just getting the necessary data with the various unix stream editors.
EDIT: I just had another look at PowerShell, and I have to admit, that it does have some really useful features that are not available for the traditional unix style tools.
For one the PowerShell owns all the commands which means that it can provide a much more coherent set of features. Parameters are treated uniformly, you can search for commands, parameters and so forth using wild cards which is really useful.
The second great feature is that PowerShell lets you enumerate sources which are normally not available to stream editors such as the Windows registry, the certificate store and so forth. Of course you can have tools that does this for you and present it as text, but the PowerShell approach is just really elegant IMO.
Take a look at PowerShell Community Extensions (PSCX), its FREE and it has Zip cmdlets:
Write-Zip
Write-BZip2
Write-GZip
http://www.codeplex.com/PowerShellCX
You should watch this presentation/discussion with Jeffrey Snover, PowerShell creator and architect. If you're not amazed by the technical details (lots of "wow" moments to be had), you'll be amazed by Jeffrey's enthusiasm :). Once you get the basics, it's easy to be very productive with PowerShell.
The answer is YES - PowerShell can use .NET assemblies. There is a bit of funny business involved in v1 if you need to wire up delegates and v2 makes that much more clean.
Just call LoadFile / LoadAssembly to get the appropriate libraries in memory and away you go
[Reflection.Assembly]::LoadFile('/path/to/sharpzip.dll')
$zip = new-object ICSharpCode.SharpZipLib.Zip.FastZip
$zip.CreateZip('C:\Sample.zip', 'C:\BuildFiles\', 'true', '^au')
# note - I didn't actually test this code
# I don't have SharpZip downloaded - just read their reference.
Also note that the PowerShell Community Extensions support various compression methods like write-zip.
I've tried to replace one of the lengthy build batch files I use with power shell. I found it a pain: at least at that time, documentation focused on the funny verbiage and what cool, perly things you can do with it, but lacked in the "getting simple things done" category. I got it working, but the error handling was to shaky.
YMMV, try powershell, you might enjoy it. But try it before updating your build batches.
My solution: use a C# console application. I've got serious logging, exception handling, can use my utility functions, and if something doesn't work I have a real debugger. It's the first solution I like to modify.
I'm not sure about powershell, but might I recommend using something like IronPython (if you want to have access to the .NET libraries) or plain python? You get a full-blown programming language with very few limitations.
On the one hand, if it works, just leave it. But it sounds like this is something you'll be adding to over time, and of course your eventual successor/coworker who needs to edit the batch file will also need to understand it. If you're from a programming background then you may well find the power of Powershell makes your script a lot shorter and easier to read/maintain (for example, even just having full if statements and for/while loops). On the other hand if you're not overly familiar with programming, a lot of people find Powershell a bit daunting at first glance.
Regarding the .NET part, Powershell is built on top of .NET so yes, you can access .NET assemblies (but you should always see if there's a cmdlet available first).
I would recommend a book called "The Powershell Cookbook" by Lee Holmes, published by O'Reilly. It provides "recipes" which you can use for common tasks; this will probably speed up your time to implement the script, and it'll teach you Powershell along the way.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I played with one of the early beta versions of PowerShell V1, but haven't used it since it went "gold". What is the best way to get started using PowerShell?
Which version of PowerShell should I be using (V1.0 vs 2.0 CTP's)? What are you using PowerShell for? Are there any tools that make using PowerShell easier (that is, development environments)?
For learning PowerShell, there are a number of great resources
Technet Virtual Labs (Introduction to Windows PowerShell)
PowerShellCommunity.org - Forums, blogs, script repository
powershell on irc.freenode.net
PowerShell podcasts - PowerScripting.net and Get-Scripting.blogspot.com
For IDE style environments, you have PowerShell Analyzer (free) and PowerGUI (free), PowerShell Plus (commercial), PrimalScript (commercial), and Admin Script Editor (commerical).
I use PowerShell for everything that I can. Right now, I'm looking at Psake, a PowerShell based build script environment. I use if for managing my Active Directory, Hyper-V, Twitter, some keyboard automation (hosting PowerShell in a winforms app to grab keystrokes), and a ton of other stuff. Another cool project I have to check out is PSExpect for testing. I also use it for database access - monitoring changes made to rows in a database by applications. It is also integrated in to my network monitoring solution.
I am also looking to use PowerShell as a scripting engine for a project I am working on.
EDIT:
If you are just learning PowerShell, I would focus on V1. As you get more comfortable, take a look at the CTP, but too much can change from the CTP to what is actually released as V2 to make that your learning tool.
Version 2 is out and available from XP SP3, Server 2003, Vista, and Server 2008 and in the box for Win7 and Server 2008 R2. What you learned for V1 will still serve you well, but now I would concentrate on V2, as there is a superior feature set.
Good luck!
To answer your questions one by one.
Get v2.0 of the CTP. I have used 1.0 and 2.0 and have not found any stability issues with the later version and it has more functionality.
The best way to get started is to learn three basic commands and start playing with it.
Step 1 - Discover the available commands using Get-Command
To find all of the "get" commands, for example, you just type:
*Get-Command get**
To find all of the "set" commands, for example, you just type:
*Get-Command set**
Step 2 - Learn how to use each command using Get-Help
To get basic help about the Get-Command commandlet type:
Get-Help Get-Command
To get more information type:
Get-Help Get-Command -full
Step 3 - Discover object properties and methods using Get-Member
Powershell is an object oriented scripting language. Everything is a fully fledged .Net object with properties and methods.
For example to get the properties and methods on the object emitted by the Get-Process commandlet type:
Get-Process | Get-Member
There are a few other concepts that you need to understand like pipes and regular expressions, but those should already be familiar if you have already done some scripting.
What am I using it for?
Two things:
Processing log files from a massively distributed grid application. For this it has proven to be incredibly valuable and powerful.
Quick testing of .Net classes.
There are a number of PowerShell tools, for example,
PowerGUI
PowerShell Plus (not free)
PowerShell in Action is a well-regarded book.
And the Powershell team has a blog.
I just found this free ebook, linked from the Windows PowerShell blog:
Mastering PowerShell
Find a problem you need to solve and sit down and do it with PowerShell until it's fixed.
Don't give in and do it another way. Then find another, and another, etc. You'll take WAY longer at the start, but you'll be building knowledge to use going forward. As well as a script library to pull from for the future. One day you'll turn around and realize you now "know" PowerShell.
It's awesome. :)
Count me in with a vote for PowerShell in Action. There are a bunch of blogs out there as well, check out //\O//'s blog, The Huddled Masses, and JB's Powershell (SQL) as well, they go way back with the shell and have gobs of good scripts & snippets to look at.
Check PowerGUI, a PowerShell GUI and script editor. I don't use it yet, but I saw the sample videos and looks very good. Also, the site mantains a library with sample scripts.
Here is another excellent PowerShell reference.
The Ars Technica tutorial is a bit dated, but very good to get you up-and-running with PowerShell.
I would also second the suggestion to check out PowerGUI.
The PowerShell CTP is NOT supported in a production environment and a lot will change between now and the time it ships. I suggest following the many PowerShell blogs (don't forget the PowerScripting podcast). There's no shortage of good books on the topic. If you want to spend a little money, SAPIEN Technologies has some self-paced learning material at www.scriptingoutpost.com. I believe Don Jones has done a series of training videos for CBT Nuggets. You can probably find out more at concentratedtechnology.com.
I think getting into the habit of automating small tasks is a great way to train yourself in PowerShell. For example, writing a throwaway script rather than doing an onerous looking bit of text-processing by hand. It may actually take longer the first few times, but as you get quicker and build up a library of useful snippets that you can chain together you can save yourself a lot of time.
There are DNRtvs on PowerShell and PowerGUI. There are also .NET Rocks! episodes about these tools.
A chap called Guy Thomas does some good introductions to PowerShell.
I would start it on the fly. What I mean by on-the-fly is that just start to work on your real case and search for help on the web or this site for help if you don't know what to do. For sure, it will very beneficial if you spend some time to learn some basics first. This is what get on to PowerShell.
I have some blog posts on PowerShell, especially 3-serials on a real case I posted recently. Search for davidchuprogramming or go here. Good luck with your PowerShell journey.
PowerGUI was a big help in and of itself. The IntelliSense feature sold me on it, then I found some useful add-ons that were very good.
As far as resources:
Free eBooks:
Windows PowerShell Cookbook
Mastering PowerShell
PowerShell A more in-depth look
Introductory Video:
http://powergui.org/entry.jspa?externalID=2278&categoryID=361
With regard to the IDE question:
There is a rudimentary IDE which, on my computer at least, is already installed with PowerShell.
It's labeled "WindowsPowerShell ISE", and lets you do things like have several console sessions and several script files open simultaneously... one set of tabs for the scripts, one set for the console sessions, so you can click back and forth as needed.