Slashdot Mirror
Ask Slashdot: Moving From *nix To Windows Automation?
Zubinix writes "I have a background in doing automation in a Unix/Linux environment using scripting languages such as perl and bash shell, as well as ssh for remote scripting. My next project will be in the Windows environment so what approach and methodology is best for developing, say, the automation required for a test system? I don't want to use things like Cygwin, as I need to integrate with Windows applications such as Exchange and Sharepoint. Is there a list of should and should not dos when it comes to Windows automation?"
Your answer to everything is WMI. Just start command prompt, type :> wmic And voila, you are ready
And why not? Powershell is perfect for the job.
Hate to say it, but you should probably learn VBScript. There's a VBScript interpreter is built into Windows, and it can interact with COM. It might be a pain, but it will suit your needs.
There's no -1 for "I don't get it."
You already mentioned using Perl in your *NIX environments so you could do the same with your Windows boxes too. You could also use Python. Powershell is probably your best option.
There are bunches of tools out of the box to automate things in Windows - the scripting host (supports js/vb), power shell, and wmi - or a combination of things. You can open a wmi interface in vb for instance.
When I was working in Software Quality Assurance we had a lot of luck with Mercury Quick Test Pro and Test Batch Runner. They have a solid recording interface than can be coded manually (in VBScript.Net but what can you do?). Integrated fabulously with C# .Net code for doing black-box and grey-box testing. I'd also suggest Symantec Ghost for setting up test systems.
-- Adam McCormick
So, been down this EXACT road. I was doing Linux automation, was so effective was brought in to do Windows too - yea!
Anyway, tried the cygwin route... It went OK, but just not quite it.
Went the vbscript route for a while (pure hell), but could work with wmi and had the windows objects available.
Soon, I started writing console apps in C# to make the trickier stuff happen. The .Net framework made it all so easy.
My final set of tools came to be powershell (access to the .net framework, you can do almost anything), Systernals psexec (for running processes on remote machines), and basic vbscript .bat. I had it set up with a web interface so I could enter a dos command into a web interface and point it a machine. It would build the bat and run it on the remote machine and return the standard out. This allowed me to add IIS sites and app pools, install com components, install apps, run msunit tests, and basically do whatever I wanted to any machine on the domain. Took me a quarter to build, but worked well. I've moved on in the company, but my replacement is still using it.
ymmv
Day 1) Walk in the door, optimistic about what can be done with this "Enterprise" platform.
Day 2) Walk in the door, with a headache, hoping to find an answer for how to manage what were simple tasks under *nix.
Day 3) Walk in the door. Sit down at your desk. Plant your head firmly on the keyboard and cry.
Day 4) Walk in the door, rip your soul out of your chest, stomp on it, and throw it in the nearest recycle bin. Sit down at your desk, and wonder why in 4 days you can't find a valid answer to automation that was so simple under *nix.
Day 5) Walk in the door. Sit down at your desk, and think about how miserable you are now that you're working on a Windows-only network. Leave 2 hours early, and drink away your pain at the nearest bar.
The longer it goes on, the worse the pain gets, until you realize that you have a stash of cheap liquor and pot in your desk drawer, and you use more of both in one day than an entire fraternity use in a hard partying weekend.
I do have some answers for parts of it. Powershell is part of the answer, but far from complete, unless you like virtually every command you type returning worthless 6 line responses. Cygwin may solve some of the problems, but not all of them. ActivePerl may solve some problems. In the end, you will realize that everything is a mouse click away, and those mouse clicks are the only way to do it. Prepare to spend the rest of your life in remote desktop connections, and putting more miles on your mouse than you ever did playing first person shooters.
Serious? Seriousness is well above my pay grade.
http://stackoverflow.com/ has experts that go there just to help with questions like this.
VBScript is included with any version of Windows you're likely to be working with, is mature, and stable. That having been said, it has the boneheaded pre-.NET Visual Basic syntax, so you may hate yourself for choosing it.
PowerShell is either included with or available as an add-on for most versions of Windows you're likely to be working with. It has a much nicer syntax that is inspired by several Unix/Linux scripting languages, and can make use of .NET assemblies, which is *very* powerful. However, my experience with it was that it wasn't 100% ready for primetime. I've written hundreds of VBScripts, but before I'd hit ten PowerShell scripts, I ran across a nasty bug related to one of the wildcard syntaces (is that even a word?) that the language supports - if I tried to use a for loop to iterate through a list of directories, and any of the directory names included square brackets, I was basically out of luck. There had been a workaround in older versions of PS, but not in the one I was using. Maybe MS eventually fixed this, but if so it literally took years.
In an ideal world, I'd recommend PowerShell, because it can do a lot more, and typically with less script code. But I play it safe by sticking with VBScript, at least until the issues with PS are worked out.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
Day 1) Walk in the door, optimistic about what can be done with this "Enterprise" platform.
Day 2) Walk in the door, with a headache, hoping to find an answer for how to manage what were simple tasks under *nix.
Day 3) Walk in the door. Sit down at your desk. Plant your head firmly on the keyboard and cry.
Day 4) Walk in the door, rip your soul out of your chest, stomp on it, and throw it in the nearest recycle bin. Sit down at your desk, and wonder why in 4 days you can't find a valid answer to automation that was so simple under *nix.
Day 5) Walk in the door. Sit down at your desk, and think about how miserable you are now that you're working on a Windows-only network. Leave 2 hours early, and drink away your pain at the nearest bar.
The longer it goes on, the worse the pain gets, until you realize that you have a stash of cheap liquor and pot in your desk drawer, and you use more of both in one day than an entire fraternity use in a hard partying weekend.
All of this is true. The answer Microsoft themselves came up with? Perl for Windows. There was also a horrible mess of garbage in CMD script that was the *nix equivalent to #!/usr/bin/perl ... so that we could run perl scripts from the command line without typing "perl scriptname.pl" first... it was about a good 25 lines of code...
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Amazingly enough, that's something I'm doing right now. (no, I'm not the original author). I smoothed over the rough spots as much as possible, and now we're doing the Linux migration. It's a long, slow process to change a decade of deep rooted Windows-isms, but it will happen soon enough. The only Windows that will be left will be the workstations for those who choose not to switch over to Linux. In a web based enterprise, there's no excuse for being locked into any platform.
Serious? Seriousness is well above my pay grade.
You can pick up a free copy ("Developer Edition") of ColdFusion from Adobe. Then code CF pages that call cfspreadsheet or cfsharepoint. (If you're careful to avoid coding directly to Windows (drive letters, backslashes, etc), the spreadsheet code you write will also work with Unix equivalents via POI.) Then use ColdFusion Administrator > Debugging & Logging > Scheduled Tasks to schedule those pages. (That's the CF equivalent of cron.)
Can't beat the price.
There's nothing fundamentally really that different from a management standpoint. The more you'll dive in the more your going to find that differences boil down to syntax. Your going to need to test your scripts, your going to need to have peer review, your going to need to use change control, maintenance windows and so on.
There is absolutely no reason for your process to be any different on the Windows side than the Unix side, and if it is than your process needs to be rebuilt. Process should always be tool agnostic and your operating system is simply a tool. If you know your best practices than the only thing you need to figure out is the syntax (tool, language etc) to do what you want to do.
If your simply asking what tools you should use to do scripting or deployment, than you need to look at tools like Altiris, SCCM and so on. If your looking for tools for packaging applications than you would at tools like Wise Packaging Studio. What you really haven't done is explained your need very well. Are you trying to manipulate certain things about exchange with a script? Are you trying to export or import SQL database data with your script?
If you want to run a script on just a few systems than you can schedule the server to run scripts manually and you just need to supply the scripts. If your looking to deploy something on a consistent basis than a combination of GPO's and Active Directory can work quite well. If your looking to automate the distribution of a series of scripts based on certain characteristics of your systems than it would be hard to beat Altiris. If you want to run custom queries or actions than WMI based scripting can do some pretty neat things.
Feel free to message me offline, where I work I'm responsible for the management of both Windows and Mac based systems and do this for a living on a daily basis.
"I am a one trick pony who cannot learn to do things in other operating systems because my ego gets in the way."
Go elsewhere to seek advice. I'd suggest stackoverflow.com
Use a decent automation engine, will save you years of headaches and maintenance. There are pros and cons though.
Ones such as BMC Bladelogic or HP Server Automation (opsware) are probably the best out there (enterprise-grade).
Be forewarned: they are not cheap. Best for enterprises 100+ systems. The more, the better ROI.
Stay away from VBScript, its very out of date at this time. Best work with Powershell, it has deep integration into Active Directory and Exchange (as well as OS, WMI etc). Its quite simple to get a script up and running, and its widely supported. It comes built into the OS in Windows 2008 onwards, for 2003 its available as a download.
One possible way is OLE automatisation, but be prepared of the horrors of it.
Why would you switch to Linux - an inferior, security ridden, and an OS which can't stay up longer than a month?!
It's a hobbyist OS at best and doesn't survive in a real commercial environment.
Don't get your hopes up with Sharepoint. This is quite possibly the single worst piece of crap ware I've encountered in the past 2 years.
Hey I'm a smiley kind of guy and I have to promote Microsoft products to undermine *nix and expand our market share, but I'm afraid I'm running out of ways to do it.
I wondered if the ever so friendly and clever Slashdot crowd can think of imaginative ways to carry out this task? Please help me. Remember; I think you're wonderful.
Powershell. The only tool that knows how to talk to all the different frameworks in Windows is Powershell. No other tool can talk to .NET, COM, WMI, native APIs (via P/Invoke), and external stdio based tools. If you can't do the automation you want using something in one of the above frameworks, you've got bigger problems than finding a good automation tool.
Since the test guy usually has to be a part time sysadmin too, you should be aware of these tools:
System update readiness tool: http://support.microsoft.com/kb/947821/en-us
WMI diagnostic utility: http://www.microsoft.com/downloads/en/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en
gplogview: http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=BCFB1955-CA1D-4F00-9CFF-6F541BAD4563
Windows SDK (including debugging tools for windows): http://www.microsoft.com/downloads/en/details.aspx?FamilyID=35AEDA01-421D-4BA5-B44B-543DC8C33A20
ollydbg: http://www.ollydbg.de/
sysinternals suite: http://technet.microsoft.com/en-us/sysinternals/bb842062
Windows Management Framework: http://support.microsoft.com/kb/968929
WDK: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff
WAIK: http://www.microsoft.com/downloads/en/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en
Windows 7 SP1 WAIK supplement: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0AEE2B4B-494B-4ADC-B174-33BC62F02C5D
If XP is involved, check out Windows SteadyState. It's like deepfreeze, if you've ever used that. qemu is also a great way to boot test machines and capture output at scale; using CoW disks you can have fresh machines every time you boot regardless if the test machines are XP or not.
-- thalakan
The only way that Microsoft can improve Windows at this point is to make it run well on virtual machines so that it can be a little bit easier to migrate away from.
Sig: I stole this sig.
I don't agree. Powershell is actually very powerful as it can extend or be extended by the .Net framework. It is also very flexible, which is very convenient for systems automation.
Big enterprise schedulers, such as Tidal, have built-in support for Powershell and many enterprise storage solutions, such as Compellent, also have built-in support. Also VMWare has the very impressive PowerCLI, which is basically a series of extensions for Powershell that can automate almost everything in VirtualCenter.
lucm, indeed.
Mouse click away you say? AutoIt
I prefer *nix too but I have a lot of Microsoft shops that I take care of. AutoIt has saved me a lot of time and effort.
Essentially, for newer versions of Exchange and SharePoint, Powershell is the only scripting option, and is excellent. For older versions, you don't have a lot of options, but you can probably call COM APIs using PowerShell as well, but the effort is a lot higher. The APIs exposed by Exchange (e.g.: MAPI) are hideous. SharePoint can be managed via direct SQL database queries from anything, with some care.
For Windows servers in general, stick to PowerShell. It's by far the best shell/scripting language by a wide margin. There's a learning curve, but it's absolutely worth it. To get set up to an equivalent level to Bash+SSH:
- Install PS2 + WinRM2 on pre-2008 R2 servers. It's not installed by default, and 2008 comes with PS1. There's a hotfix that updates PowerShell and all associated components to v2 on XP, 2003, Vista, and 2008. .ps1 script files from running by default is a shit workaround for not having an execute bit, and is totally useless. Just turn it off.
- Enable unsigned scripts to run. Preventing
- Enable WinRM. This is the equivalent of SSH, but has to be enabled on both servers (which is obvious), and the clients (for no discernible reason).
- Enable CredSSP. This improves WinRM by allowing delegated credentials to be used remotely. Unlike SSH, WinRM is an RPC protocol, and due to limitations of Windows authentication, the remote server cannot use network resources with the client's credentials (one hop security). The workaround is credentials delegation. This requires a server-side setting, and two client-side settings.
- Install plugins. There are about a dozen that ship with Windows 2008 R2, a plugin for Exchange 2007 and 2010, and a plugin for Sharepoint. To set up the AD plugin on pre-2008 R2 domains, there's a module that has to be deployed, it's basically a web service that the PS plugin uses. The SQL plugin is an optional download that is particularly handy for SharePoint.
That seems like a lot, but can be done in seconds from the command-line, and even better, can be done completely automatically using Group Policy. For new server deployments, I ask for my servers to be created under an AD container, and I just set those options up in a common policy configured on that container, and then everything just works.
The equivalent of a remote SSH session in: Enter-PSSession 'computername'
However, it gets better: You can create and store sessions in variables by creating them using New-PSSession. You can pipe objects into remote sessions and invoke commands on them, or arrays of them. In other words, a single line of code lets you invoke commands in bulk across farms of servers.
For example, as a Citrix XenApp admin, I often have to update machine policy across a farm. This is just two lines with PowerShell:
$xaservers = Get-XAServer | Select -ExpandProperty ServerName
Invoke-Command -CN $xaservers { gpupdate }
That will query the list of XenApp servers, extract the server names into an array, and invoke "gpupdate" in parallel across all of them using a temporary secure shell session.
There might be equivalent capabilities on Linux, but nothing on the Windows platform comes close to what you can do with PowerShell.
You can also package up ruby and python scripts into standalone .exe's, that do NOT need installed ruby or python interpreters on the target system. These standalone executables are very slow to start up, though.
Oddly enough, I am not convinced. What the heck does it mean that PS can extend the .Net framework, and itself be extended by .Net? Also, for a program to have "built-in support" for PS doesn't make much sense at all because PS is a shell environment. Quite honestly, your post just seems like a bunch of buzzwords. To be more convincing, I would like to see some example commands showcasing the power and flexibility of PS.
http://img546.imageshack.us/img546/2518/imageinf.jpg
Signature Pro version 1.13.2-3 release 83.5 beta3try7 after-breakfast edition
Those cli utilities are 30 plus years old. Any sysadmin worth his salt will know them inside and out. How is the syntax any more arcane than what is spit out by ps? And, er, last I checked the ease with which completely unrelated utilities can be chained is the point!
The soylentnews experiment has been a dismal failure.
Those cli utilities are 30 plus years old. Any sysadmin worth his salt will know them inside and out. How is the syntax any more arcane than what is spit out by ps? And, er, last I checked the ease with which completely unrelated utilities can be chained is the point!
"Arcane" is a term that is only ever used to describe a non-Microsoft OS, sort of like the way the word "upstate" is only ever used to describe a region of the state of New York.
It is shorthand for "I don't know anything about it, therefore something is wrong with it."
It is a miracle that curiosity survives formal education. - Einstein
If you're comfortable with Perl, it's definitely something you can bring with you to the Windows world. You can use Strawberry Perl with or without Cygwin. If you need to deploy code, you can use PAR::Packer's pp utility to wrap your script, its included modules, and the perl interpreter into a standalone executable.
Perl can do a ridiculous amount of stuff when you start using modules from CPAN. The Windows world is very GUI heavy, but a lot of things can be done using CPAN modules. Writing to Word docs. Controlling VMWare. Networking with just about every protocol you can think of. Creating GUI applications for others to use. There's also a nifty little module called Win32::GuiTest which will let you programmatically control GUI programs that don't provide a command line interface.
Good luck!
Been there, been asked to to that. In my case, management had their head up their ass.
In a s/w project, part of the platform architecture decision is: What resources do we have available to support each option? By the time the Windows/Exchange/Sharepoint decision was made, the resources available to support development and maintenance should already have been identified. So some genius picked the platform and then realized that all they had was a *NIX guy?
You don't decide to field a football team (yes, but what kind of football, you ask) and then realize that all you have are basketball players.
In my case, I offered to distill the requirements down to a platform independent set and build the system the way I knew how. They could go find some Windows wizards and give their implementation a try. The Windows version was never completed.
Have gnu, will travel.
Best Practices aren't just an abstract outline of how to solve a problem, they also incorporate some level of practical detail as to how to go about solving the problem. Best Practices don't necessarily (or should) include implementation details, but they must be at least aware of how the implementation differences impact the choice of solutions and methodologies.
In my case, I help run the development build system for Oracle's JDK and the associated OpenJDK project. We have Linux, Solaris, Windows, and Mac to deal with, across multiple CPU architectures. While the conceptual design of the system started out being simple, we've found that the quirks of each OS require a rather significantly different approach to solving the same problem on each platform. What works on Solaris doesn't work well under Windows, et al. This kind of thing is common in multi-platform environments, where the most efficient method of doing someone on one platform can be severely sub-optimal other places.
Back to the Question: my answer is that you should likely give up on the techniques you found worked well under *nix. You want to use the Native Windows tools. Powershell and a native Python implementation work very well for basic stuff, but you'll likely want to crack open a copy of Visual Studio and actually do some .Net development for anything rather complex. I've particularly found that several common assumptions under *nix aren't true in Windows (e.g. process manipulation/management is very different), and you really need to move into the Windows mindset to get a good design and implementation going.
There are always four sides to every story: your side, their side, the truth, and what really happened.
You bring up a good point, but I'm going to address this to the OP.
As previously noted by the other commenter, Powershell is useful if your environment is full of Vista computers or newer or if you have more control over the environment so Powershell can be installed (there is an XP installer). It's major draw is the usefulness to systems admins that want to do real-time execution.
Otherwise, you're looking at VBScript or batch scripts. Neither are nowhere near as elegant or smooth as some other languages, but tapping WMI and other Windows objects is actually really simple using VBScript. There are loads of examples here. Also, a Google search in the form of "vbscript %thing%" will usually get you pointed in the right direction.
Do yourself a huge favor, though - get a decent editor. While Windows has a simple notepad app, there is no context highlighting, in-line completion, or other helpful tools for looking at script code. Personally, I prefer PrimalScript because it's useful for other things like SQL, C, Perl, etc (including PowerShell). It also has a built-in debugging engine. However, that app can be expensive. One good free alternative is Notepad++ with the appropriate plug-ins for the files you want to create/edit. There are plenty of others out there, so grab whatever you feel works best for you.
If you're planning on using a database and are familiar with MySQL, you should feel nearly at home with Microsoft's version of SQL. There are some minor syntax differences (for example, the update query is slightly different, if my memory is correct) but it shouldn't take long to get used to them.
Lastly, ideally, you're going to want to an account that is a local administrator on all of the systems you will be touching. Yes, you can do some serious damage with such an account and is typically not the way of things in the *nix world, but many aspects of a Windows system are inaccessible unless you have an Administrator level account - especially remote access to certain things like the registry and WMI. If getting a local administrator account on all the systems you're responsible for isn't an option, have someone that does have one (or a domain admin account) on speed-dial in case your scripts fail due to permissions errors.
Good luck!
My sources are unreliable, but their information is fascinating. -- Ashleigh Brilliant
Careful, SSH and haphazard interfaces do not play in Linux's favor.
Day 1) Walk in the door, optimistic about what can be done with this "Enterprise" platform.
You know this works exactly the same way s/Windows/Linux/ and vice-versa
I use Puppet for doing Linux configuration management, and it is an _awesome_ tool but shows just how much Linux is lacking in basic system instrumentation, configuration management, and datacenter level administration. That is an area Windows has a leg up.
Kerberos + formal APIs beats SSH + only standardized interfaces are 30 years old
Think what it takes to programmatically manage crontab entries for a minute, compared to something with an API for scheduled tasks built in.
It's not even a contest, Linux is HORRIFIC at programatic configuration, you cannot lie about this.
If SSH is your idea of remote automation heaven, then I hate to tell you, but you can install that on Windows. There's a good chance you wouldn't need to if its kerberized WMI interface does what you need, and you can't just install "instrumentation" into Linux. And these are standard interfaces I'm talking about .. http://www.dmtf.org/
Once you get to the datacenter level, doing things programmatically is KEY. This SSH + messy nondeterministic CLI bullcrap doesn't cut it.
Sorry, but you home Linux admins that think Linux is the tits needs to wake up. Microsoft is reeling right now, but Linux vendors are getting complacent. As complacent as Microsoft was...
At least document fucking return codes, and do something useful with them if you can't write out something parseable! Sun got that much right for Chirst's sake, and Linux fanbois like to pretend their are working on a UNIX system. Want an example??
man yum, tell me how you would know if a package installed or not when I do "yum -y update foo"
That is the bullcrap I'm talking about. OS updates... not exactly some obscure interface huh?
I'm a *nix guy, and I do have to say Powershell is pretty sweet.
Here's an example of something extending Powershell. VMWare released a module for PowerShell that allows for control of VMWare env using Powershell.
#Load VMWare snap-in for powershell
LoadSnapin -PSSnapinName "VMware.VimAutomation.Core"
#Create VM from template and then start it
$myNewVMName = "NewVM_01"
$myTemplate = Get-Template "TemplateName"
$strDestinationHost = "ESX01"
$myNewVM = New-VM -Name $myNewVMName -Template $myTemplate -VMHost (Get-VMHost $strDestinationHost)
Start-VM $myNewVM
VMWare created a really awesome extension to Powershell, that allows for all sorts of inheritance and piping. Microsoft created a rather poorly implemented Active Directory extension for Powershell (can't pipe or inherit on things I would expect to be able to)... MS could have used the VMWare example to make a better AD extension.
Let me know when it's as ubiquitous as bash or csh. As far as I know, it's only pre-installed on Windows Server 2008 or greater.
Okay. It's as ubiquitous as bash or csh. It ships out of the box with Windows Vista, 7, Server 2008 and 2008 R2, and for XP it is included in Windows Update so any computer properly receiving it's updates will have it.
Uh, Powershell commandlets don't actually return text responses at all, they return .NET objects which can be represented as serialized XML. They turn into "worthless 6 line responses" when you pass those objects / XML to the default text formatting output, which is implicit when you are using Powershell shell. This is one of the reasons Powershell is great, no serialization and reparsing occurs when passing and piping data between commandlets and the object structure and it's associated methods are maintained.
bash...
Probably the hardest thing to learn in the *nix scripting world is sed.
I wrote a menuing system for a Xenix minicomputer back in the early 1990s in straight sh, never having touched it or the Unix tool set before, in a couple of hours. And I can tell you I ain't no genius.
Try do anything vaguely useful in Powershell without prior knowledge in a couple of hours. It is a gawdawful horror story, a good example of the insane overkill that Microsoft applies to simple problems. It keeps the MCSE's employed with the bizarre range of esoteric and overly-complicated solutions, but when you're just trying to move some data around from tool to tool or piping some output through a regex evaluator on its way to a SQL RDBMS, you end up going "What the fuck is wrong with those people in Redmond?"
The world's burning. Moped Jesus spotted on I50. Details at 11.
Ruby has for years come with a wrapper library for Win32OLE.DLL, which in turn allows you to automate any program that acts as an OLE client, like IE, Excel, etc.
As long as the program has OLE hooks, you can control whatever functions it makes available via OLE. Another tool that is often used with Ruby in the Windows environment is AutoIt!, a Windows scripting tool, which itself (I believe) operates through the OLE interface.
I have had similar problem. I cant say its good or bad but I adpated myself to use batch programming but I heavily use Gnuwin32 ports and UnxUtils that give most of the Unix commands as exe http://gnuwin32.sourceforge.net/ http://sourceforge.net/projects/unxutils/ Happy Hacker
Powershell is great, but not what I would call a great GUI test tool. Sure it can be done, but you're going to need some snapins and there are limitations. Also you may have to write to the lowest common denominator, and if that is XP that may be Powershell 1.0, and that is quite limited IMO (you could download 2.0, which is now available for XP, but it wasn't when I was using powershell). I personally had to abandon my Powershell work, which was more command line than gui because management wanted the upgrade code to be a single script for all platforms and then they added Linux support to the mix (so I kinda moved in the opposite direction of the original poster).
Don't be shy. Tell us how you really feel.
There's a product called PowerWF Studio from Devfarm software that combines the best of building block "drag and drop" workflow development with an excellent Powershell editor. Definitely worth a look for this type of situation.
FD: I don't work for the company, but I happen to be friends with the owner. I'd recommend looking at it regardless.
Comment removed based on user account deletion
This is false. Powershell is available as an addon for Win XP and Win 2k3. The poster above said preinstalled fo a reason. Any decent Window environment should have a software distribution system which makes the update for PS 2.0 a non issue.
I dunno. When it comes to Linux, arcane seems to mean that the syntax is not consistent or some other weird thing.
Yes, you're right however. The term is used by people who are less experienced with Linux, and the frustration arises every couple/few months or so when a configuration change or something is needed, and the CLI tools often use different syntax or are otherwise inconsistent with the rest.
Sure, to the Linux vets, it's all stuff that's been used and learned for awhile. But for those of us that leave a Linux box alone and rarely need to jump into any config stuff, the syntax IS arcane.
Someone flopped a steamer in the gene pool.
only standardized interfaces are 30 years old
The mouse is almost 50 years old. You'll have to be way more specific about what's actually wrong with the interfaces that exist, standard or otherwise.
Think what it takes to programmatically manage crontab entries for a minute,
99% of all tasks I want to schedule with something like Cron need to run hourly or daily. It is a one-liner to add an hourly, daily, weekly, or monthly cron job. Oh, and there's a cron.d on my system.
It's not even a contest, Linux is HORRIFIC at programatic configuration, you cannot lie about this.
Erm... if you say so. I mean, I can also put my entire cron configuration in version control -- hell, I can put my entire /etc under version control, and I can get meaningful diffs/patches, comments, etc. Can you say the same for Windows configuration?
If SSH is your idea of remote automation heaven, then I hate to tell you, but you can install that on Windows.
Yes, and you can install Kerberos on Linux. That buys you nothing. SSH sucks as a method to automate Windows, certainly, but that doesn't tell us much either.
messy nondeterministic CLI
I find it really bizarre that you can say that in the same breath. Nondeterministic... so other APIs are deterministic? What do you mean by that?
man yum, tell me how you would know if a package installed or not when I do "yum -y update foo"
Probably couldn't get it from that one command, but I could check the status before or after the fact:
It is true, the exit code isn't documented, but it is fairly standard that success is 0, anything else is an error. I just checked on a redhat system -- "yum list ksh" shows me that ksh is available, and returns 0. "yum list installed ksh" errors and returns 1, since ksh isn't installed -- but repeat the same with dash, which is installed, and it returns 0.
Should that be documented? Sure, but this isn't exactly "undocumented, may change suddenly with disastrous results!" territory here. Never mind that the output is easily parseable.
Oh, and... OS updates... Say, when can I expect an API to deliver my app via Windows Update, hmm? At least updates to it, if not the full installation?
Don't thank God, thank a doctor!
How about Perl or ReXX instead of Powershell? What would slashdotters see as their advantages and disadvantages compared to Powershell?
There is likely to be a reasonable selection of earlier work available in both, even for Windows.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
I would like to subscribe to your newsletter.
Try the veal.
-- Terry
I'm sorry. I'm really not trying to be obtuse; this is a serious question.
How is any of that different from shell scripts?
One of PowerShells roles is indeed shell scripting. As shell scripting it is really powerful and robust. It has a very consistent syntax, borrows from *nix pipe paradigm (but improved upon it with object-oriented pipes), has an very advanced scripting language with structured exception handling, optionally static/dynamic typing, closures etc.
PowerShell defines a lot of infrastructure and conventions directly aimed at shell scripting, e.g. all commands which can somehow change system state (write to files, change registry entries, delete directory entries) supports the -whatif and -confirm parameters. These allow you to run a script in simulated mode or in a mode where you are prompted to accept or reject each change. PS infrastructure makes it easy to build the same support into your own cmdlets, functions and scripts.
Shell scripting is but one of its roles. PS has also been designed to be a automation engine to be used within applications, e.g. GUI applications. The PS commands (called cmdlets) use strongly typed parameters as opposed to weakly typed (text-only) parameters in traditional shells. Also, the PS execution model is to *not* spin up external processes when executing commands, but to process the cmdlets in-process.
This means that cmdlets are really well positioned to become the back-end of a GUI application, essentially using the same class as an implementation of the command pattern in a GUI tool and as a PS cmdlet. You *can* do this with traditional *nix tools, but the text serialization/deserialization and separate-process model constantly get in the way, not to mention the fact that there are some objects which are not at all suited to be represented as text in the first place. PS cmdlets can manipulate in-process (in-memory) objects passed to them without serialization. This is what they do on the PS pipeline and what they'll do when PS is used as an in-process engine within a GUI application.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Might not have much of a choice.
**gripes**
Here are my gripes about windows from an admin POV:
1) Unlike unix/unixlike OSes with Windows quite often you cannot rename/move/delete files/dirs that are in use. You might be able to do it in some cases, but not others, it's quite annoying if you are trying to atomically change/upgrade/update stuff without rebooting/restarting too much crap. You may think this is a small thing, but it has a major effect/limit on how you do stuff on windows (even Microsoft has to force reboots to change files).
So you may have to resort to stuff like this: http://technet.microsoft.com/en-us/sysinternals/bb897556
Might not be as big an issue once you're large enough to use load balancers :).
2) The fine grained ACLs are good, but they often don't seem to work properly. On Win2k8 I've encountered cases where an account belongs to the Administrator's group but it somehow does not have enough permissions to rewrite/save a file that "full access" permissions to those in the Administrator's group. Why can't I open the file, change it and save it back? When I use that account to copy a file onto that file I get a "privilege escalation" prompt and if I "OK" it it overwrites the file. So the account is definitely in the Administrators group already...
3) I don't know why but lots of Windows stuff tends to have crappy logging by default. You often have unhelpful error messages that say "it hurts", but not tell you where it hurts, or what was being attempted, or what the target was. Some are even more useless! e.g. "UVD Information".
In theory this shouldn't be OS related but somehow I've had a lot less trouble figuring out what's going on from logs in linux/*bsd machines than from windows machines -e.g. it's faster/easier to figure out why email is not being received/sent with the former than the latter.
Searching for stuff in windows event logs is also a pain and a lot slower than using tail and grep on the unix/linux text logs.
4) Too often nobody seems to know what things actually do or how things actually work, not even people working for Microsoft - (e.g. this is not the full story: http://blogs.msdn.com/b/oldnewthing/archive/2007/10/08/5351207.aspx
Apparently there's stuff like a not very documented ITaskList_Deleted property which also affects how windows are handled...
Then there's the ServerXMLHTTP vs XMLHTTP - my colleague found out the hard way that there are cases where ServerXMLHTTP works and XMLHTTP doesn't - he still doesn't know why. I've not seen documentation on the real technical differences - this is light on the details: http://support.microsoft.com/kb/290761 ).
As a result there are messageboards, blogs and docs filled with incorrect information.
And there's often no practical way to find out (unless you're an uberhacker who can disassemble megabytes of code in your sleep). With OSS stuff, at least you can look at the source and have a better idea (but sometimes you just go wow it's amazing that stuff even works, maybe I should use something else ;) ).
**tips** ;).
OK end of grumbling, here's what I use for when the automation breaks down
1) Add notepad, texteditor and hexeditor shortcuts to your SendTo folder. If you are unclear on where your SendTo folder is (because of roaming profiles or other weirdness), go to start, and run shell:sendto
Once you've done that you can right click on any file and open it with your editor/program of choice (add media player classic or VLC if you want ;) ).
2) create a folder for utilities. e.g. c:\util or c:\bin and add it to your path (WinXP: winkey+pause, advanced, environment variables, system variables, path. Win2K8:start,right click computer, manage, advanced or something
No, it really wasn't. I was just trying to avoid being called a troll by Windows lovers. I have been doing Windows Server admin now for 3 years. Linux, it may take some effort to get everything to work the first time, especially if you don't mess with automation a lot but, once you get it to work, it always works. With Windows, it's always about success rates. Even under ideal conditions, you can't get above 97% successful on large user base. Then you have to manually fix the 3%+ that failed. You spend a lot of time using remote desktop. I don't care if it is hard to set up if it'll run the same way every time. The WMI interface that many people have repeatedly brought up fails a lot more than they would like to admit. The only thing that can be relied upon to run 100% of the time is the cmd shell which is very limited. KIX helps a lot but, even it doesn't return 100% and you have to write more debug code than code if you want to find out who failed and why (assuming it was able to launch). Even piling on using Altiris, BixFix and AutoIT, at a ridiculous cost, can't seem to crack that 97% rate but, it'll keep you closer to it. If it was the same machines failing all the time, we'd just replace them but, it's always random and that's the fucking problem.
I'm still floored that I got first post. I wasn't expecting that...
"Be particularly skeptical when presented with evidence confirming what you already believe." -
Actually, I was referring to this text.
More often than not, when I've done something wrong slightly wrong, I don't get anything useful back. Someone mentioned "Perl for Windows" comes with Windows now. Bah.
I know, I know, install ActivePerl. But installing a 3rd party package does *not* mean that it comes with it. I was trying to use Windows Services for Unix (SFU). I was trying to do a comparison on SMB to CIFS to NFS for access speed tests. It was a Linux server, with Win2k3AS and Win2k8 Server VM's. If you ever want to give yourself a massive headache, try this. I also connected to the same services with a stand-alone Linux (Slackware64) machine. The standalone machine had no problems. Trying to get SFU (which I read as Shut the Fuck Up) was a painful exercise in how not to get anything done for two days. As I recall, I did finally get it installed. I'm pretty sure it was the Win2k3AS server that required a download from Microsoft, and their one and only link for downloading the 150MB (if I recall right) file was broken, so I finally got it from a 3rd party who happened to have a copy.
Oh, and setting up the Linux client? About 10 minutes, and that was because I was interrupted a few times. Come on, setting a service to run (chmod 755 /etc/rc.d/rc.nfsd), a few lines in fstab, and it's done. Samba or CIFS? chmod 755 /etc/rc.d/rc.samba, a few lines in fstab, and it's done.
Right now, I'm looking at the lovely possibliity of changing the file shares on every machine on the network. Everyone has a dozen or so shares mounted, and they're all different drive letters. The easy way to find out? I scanned them all in Cygwin.
Serious? Seriousness is well above my pay grade.
I can do the same thing in 3 lines of code using only SSH and virsh in our KVM environment (1 line to set sh as shell, 1 to run SSH and use virsh to clone / create a VM, and 1 to start it).
And I can do that with 1 line of PowerShell code (PowerShell has a consistent way to short parameters, use positional parameters and pipe full objects like virtual machines):
new-vm ESX01 -name NewVM_01 -templ TemplateName | start-vm
Your point? The OP was asking what to use to set up and administer test systems in a *Windows* environment. PowerShell is a valid option for that.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
I'm a programmer-slash-sysadmin, and I've taken a stab at writing both command-line tools using C/C++, .NET, and these days with PowerShell, so I might be able to answer your question.
When I write complex software, I usually provide some command-line tools for the admins to do things like import data, export logs, or whatever. This is a royal pain in the ass, but I do it because it's useful. I always end up spending something like 80% of the time on annoying stuff like handling command-line parameters, input validation, and error messages. Of course, because whatever I come up with is new and different, I have to write doco for it, train staff, and so on.
Now, with PowerShell, instead of having to write a whole new program to implement a command, I can simply extend a class from a framework library. The PS framework does almost everything automagically: handle the pipeline, input parameters, parameter validation, parameter sets, optional parameters, help, tab-complete, wildcard matching, output formatting, etc...
To give you an idea, it is possible to write a PowerShell command in C# (.NET) with several parameters and complex output that does a useful task in about 50 lines of rather trivial code. The equivalent C program would be thousands of lines.
More importantly, the resulting PowerShell command will be orthogonal, consistent, discoverable, and embeddable
By orthogonal, I mean things like: every PS command that handles wildcards does it with the same shared library, which is trivial to use. Hence, I can do things like: Get-VM "prod_win_[a-k]*" which is a VMware snapin, and the behavior will be exactly the same as if I had called a Citrix XenApp snapin to lists farm servers with: Get-XAServer "prod_win_[a-k]*". Similarly, the output of commands is structured data. You can say: Get-VM | Export-CSV or Get-XAServer | Export-Csv and get similar results. Compare with legacy command line tools, which often implement such formatting internally, and badly. I just had to work on some Novell systems, for example, which export invalid XML files because the utility doesn't escape ampersands! Of course, our example 50 line command will get all of that. Export to CSV? You have it! Export to XML? Done! Quickly, tell me how to export CSV formatted data from the following 3 Linux command-line tools: 'ls', 'apt-get', and 'ps'.
By consistent, I mean that parameters are always specified with "-param", never "/param", or "--param", or "-abcdgh" where each letter does something that you can only determine by reading a five page document. Similarly, Microsoft has established a strict naming system for developers, so that instead of "retrieve-foo", "ask-foo", "query-foo", "request-foo", "list-foo", "foo-list", "fooenum", or god knows what else, the only acceptable standard is "get-foo". VMware has "Get-VM", Citrix has "Get-XAServer", Microsoft has "Get-Process", etc... no guessing! There are standards for command names, parameter names, and coding conventions. E.g.: Verb Naming Rules, and Cmdlet Development Guidelines.
By discoverable, I mean that if I write a little 50-line utility with a bunch of parameters, an administrator at the command line can simply press 'tab' and have both the command and the parameter names automatically completed. The help is automatically generated from my 50 lines of code. GUI script wizards can load a bunch of metadata about each parameter to enable drag & drop script development.
By embeddable, I mean that even a 50-line utility can be called not just from the shell, but from within a hosting application in the same process. Instead of having to handle text-based streams, PS commands take .NET objects, and return .NET objects. There's no guessw
How exactly do you see Windows updates for all packages again? Oh, right, it's not a feature. Yawn.
Ignorance can be cured by Google (or bing). It took me 30 seconds to find out that Windows Update does indeed have a COM API which can be readily used from PowerShell. Here a way to list *all* available packages from Microsoft Update:
PS C:\Windows\system32> $mus = new-object -com "Microsoft.Update.Session"
PS C:\Windows\system32> $updates = $mus.CreateUpdateSearcher().Search("") | select -exp updates
PS C:\Windows\system32> $updates|select title
Title
-----
Latvian Language Pack - Windows 7 Service Pack 1 (KB2483139)
Slovenian Language Pack - Windows 7 Service Pack 1 (KB2483139)
( other language packs )
Definition Update for Microsoft Security Essentials - KB2310138 (Definition 1.103.1197.0)
Note how the list was produced by selecting just the title. The updates returned by the update searcher are actually objects which not only expose a lot of extra information such as disk/cpu/memory capacity recommendations, severity indicators from the security response team, knowledge base article references, license text etc, but also allows you to directly proceed to install by piping them.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
bash...
Probably the hardest thing to learn in the *nix scripting world is sed.
I wrote a menuing system for a Xenix minicomputer back in the early 1990s in straight sh, never having touched it or the Unix tool set before, in a couple of hours. And I can tell you I ain't no genius.
Try do anything vaguely useful in Powershell without prior knowledge in a couple of hours. It is a gawdawful horror story, a good example of the insane overkill that Microsoft applies to simple problems. It keeps the MCSE's employed with the bizarre range of esoteric and overly-complicated solutions, but when you're just trying to move some data around from tool to tool or piping some output through a regex evaluator on its way to a SQL RDBMS, you end up going "What the fuck is wrong with those people in Redmond?"
Just as a reality check, here's a single command line that:
- gets the Windows security Event Log
- filters for failed logon events (4648)
- extracts some fields from the events, in some cases these are exposed as simple properties of the streaming objects, in one other it's using RexEx, with a named capturing group, to find the user name in the message
- inserts the data in a SQL RDBMS
Get-EventLog -LogName "Security" | ? { $_.InstanceID -eq 4648 } | Select Index, TimeGenerated, MachineName, @{Name="AccountName"; Expression={(([regex]"Account Name:\s*(?.*)\x0d\x0a").Match($_.Message) | ? {$_.Success}).Groups['AccountName'].Value}} | % { Invoke-Sqlcmd -Query "INSERT INTO tempdb.dbo.FailedLogons VALUES ($($_.Index), '$($_.TimeGenerated)', '$($_.MachineName)', '$($_.AccountName)');" }
I'm no genius either, have no MCSE, been into Xenix last century, but oddly enough I ended up with a completely different opinion of the people in Redmond.
Just to be sure I'm not making up things, this is the database schema to test it with SQL Server:
CREATE TABLE tempdb.dbo.FailedLogons ( LogIndex int NOT NULL PRIMARY KEY , TimeGenerated datetime NOT NULL , MachineName nvarchar(16) NOT NULL , AccountName nvarchar(256) NOT NULL )
Oh, and you need to make sure SQL Server PowerShell provider is loaded in your environment for the Invoke-Sqlcmd commandlet to be available.
This is a more complex problem than what scripting language you are going to use. Automating things is about job management, process management, signals, connecting streams and terminals, setting device modes, filesystem permissions, modifying network settings, and many other things.
Agreed. And that is what PowerShell excels at - on the Windows platform.
Unix is designed in a way that lets you change almost every property of the system in numerous ways, following general principles of its architecture. It is a very logical and consistent system.
Yes, bit the fact that Unix same up with this good idea 30 years ago does not mean that it is *the only* such system or even that the *nix way of doing things cannot be improved upon.
The problem is that Windows lacks such an modular, abstract foundation.
Are you for real? Have you any idea about Windows foundation? Unlike Unix, Windows' foundation is almost exclusively object-oriented. Most/all core API are exposed through COM which is an object-oriented foundation which allow much finer-grained access than command-line utilities and text file fiddling.
It is a much more arbitrary and inflexible system, it is not designed for putting different pieces of it together in different ways for automation.
Read up on PowerShell. PowerShell works with COM, WMI and .NET and thus can reach any part of the system and all applications which expose automation APIs or which is based on .NET.
For example, on Unix you have numerous small utilities that work together nicely by piping the output of one utility into the input of another one. Windows is really bad at doing such things, and the output format of most of its utilities is not easily machine parseable.
But those "small utilities" are really small monoliths. You cannot interact with them as they run expect through the input stream. You spawn them and listen for their output. Compare that to PowerShell manipulating objects. As an example just consider the ps command. In PowerShell it returns not text but a collection of Process objects, each describing the process. These objects can be piped through other cmdlets which can call methods on those objects, like e.g. Refresh, Kill, WaitForExit or drill down into threads or handles, all from the returned object. With Unix you have to ask the utilities to output in a certain format or use entirely separate utilities.
Consider for example why ls has so many options for controlling output (I list here only the options for somehow controlling the output format and/or sorting):
man ls
(a lot of options)
Now, is that a simple utility? I can count some 50+ formatting/sorting options in this command alone. Why does a command which is supposed to list files and directories have so many options for controlling the output format? Is it to please cranky sysadmins who will only accept to view listings in a specific format, or is to to adapt to the requirements of other commands? The constant formatting and parsing is error prone and thus commands now include options to make sure that e.g. dates can be formatted and parsed in a way as to avoid strange effects when run in a different environment.
After that consider ps which has it's own set of options for controlling output to allow for further processing. Why do all commands have to be concerned about this, often using conflicting concepts and option names? How is this "do one task only and do it well"?
Then look at PowerShells ls command (alias for Get-ChildItem):
PS> get-help ls
NAME
Get-ChildItem
SYNOPSIS
Gets the items and child items in one or more specified locations.
SYNTAX
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Linux is HORRIFIC at programatic configuration, you cannot lie about this.
How am I able to deploy Linux mail servers / spam filters to our customers in under 45 minutes using a ton of automation, yet it still takes me days to get their Exchange servers online? I spend most of the time installing updates and hunting for cryptic powershell commands just so I can increase the 10 MB e-mail limit in the 7 different places Microsoft imposes that limit.
I'm not saying it can't be automated, it's just a major pain in the ass--oh, and the 'reference' or 'test' box you are going to use to setup your initial automation will cost you thousands in licensing costs.
If SSH is your idea of remote automation heaven, then I hate to tell you, but you can install that on Windows.
Installing SSH on Windows is nearly useless because their CLI is nearly useless. Who wants to access such a limited interface?
programmatically is KEY. This SSH + messy nondeterministic CLI bullcrap doesn't cut it.
Really? How's Amazon doing it? Are they running Windows Servers to provide their cloud services?
How about Google? I seem to remember them mentioning something about Windows being too cumbersome to support their operations.
Remember Hotmail before Microsoft bought it? All running BSD. Then do you remember the hilarity when Microsoft bought it, there was a ton of downtime, and their engineers accidentally leaked the document saying that it would be prohibitively expensive (millions) for a company to built a service like hotmail with Microsoft's overpriced software?
Sorry, but you home Linux admins that think Linux is the tits needs to wake up.
I did--now I 'admin' linux servers commercially.
The other guy on my team was just required to switch from managing a stratus running Linux to an entirely Windows environment. He used to have evenings and weekends free, now his pager is going off constantly due to bluescreens, crashes, failed updates, hangs, etc... He turned in his notice after 10 years because of the abomination of managing Windows in an industrial environment.
At least document fucking return codes, and do something useful with them if you can't write out something parseable!
0 = good ;)
Anything else = bad
That wasn't so hard, was it?
Sun got that much right for Chirst's sake, and Linux fanbois like to pretend their are working on a UNIX system. Want an example??
man yum, tell me how you would know if a package installed or not when I do "yum -y update foo"
I can't answer that one. I don't mess with RedHat and it's ilk. That is the bullcrap I'm talking about. OS updates... not exactly some obscure interface huh?
There's no place like
And maybe you want to hone up on your writing skills? You wrote
How exactly do you see Windows updates for all packages again?
You wrote Windows with a capital W. If you meant to hit on the fact that there's no central repository for 3rd party packages you should have left out the Windows part, like
How exactly do you see updates for all packages again?
See? not too difficult.
Anyway, having a central repository has very little to do with automating a test system. For automating setting up a test system having the packages available will do just nicely. Pathetic that you must move the goalposts to keep the illusion that Windows is no good.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
The point was the grandstanding, the comment "I do have to say Powershell is pretty sweet" implied something interesting or insightful was going on.
There is. PowerShell is a refreshing new take on shell scripting. Granted, it is best fit for Windows because Windows is already pretty much object oriented from a system point of view. But at the same time traditional shells would struggle with incorporating OO concepts. PowerShell does away with the need for sed and awk, has a built-in extremely powerful regex engine and has modern constructs like structured exceptions, script blocks, closures, integrated help (no not just man pages) and a lot of other interesting stuff like the common -whatif and -confirm parameters, remote sessions and remote jobs, fan-out remoting etc.
You may not like the fact that Windows now sports a shell which surpasses bash, ksh and zsh in many ways, but that doesn't mean that it is not interesting. It is for a good many of us.
Half of the people in this thread make it sound like this is such a big deal, and it's still a pile of steaming crap.
Yeah, whatever. You are entitled to your opinion. But please educate yourself on the subject.
It's like I've stumbled into some bizarro-world edition of Slashdot where getting a limited command shell to function under Windows is some sort of nirvana. You still have a (very very very) limited shell with little of the functionality of shells created 20+ years ago.
Translation: "Help, someone in here has something good to say about Windows and nobody helps me with bashing them. Anything coming from Windows cannot possibly bring anything new. I refuse to look at it. If it is any good, it must have existed for 20+ years in Unix".
Grow up, please. PowerShell is a full-featured command shell and surpasses bash, ksh and zsh in several areas. You may still prefer *sh shells, but on Windows there is an interesting new take on the concept.
Or, to put it simply, "there is nothing to see here". What you think of as the Rapture is a meh moment at best.
Translation: "I don't want to hear about anything which could challenge what I already know as the truth."
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
Are you trying to be dense? What's in the XML?
Or, alternatively, "Yeah, Plain Text is really proprietary, impossible to decipher without reverse engineering; the worst format for interoperability."
We're talking about theoretical improvements of PowerShell, and this whole thread was about .NET bits autoparsing XML. Once you move away from .NET you're exactly piping plaintext (like *nix) except you have to parse a whole XML tree to get it.
Powershell might be better than cmd batch files, but don't expect to be able to write a script that will run on machines that haven't had Powershell explicitly installed. I attempted to use Powershell for a simple automation task, but couldn't write a script for automating something and expect it would work at all on a client's machine like I probably could if it were a Unix shell.
Running software in Windows is a massive pain because there is no good way for the shell to find commands, so scripts that depend on external programs need to jump through hoops to find the appropriate binaries.
I ended up whipping up a quick program in C# to do the automation; it took less time than trying to figure out Powershell, didn't require many dependencies and could provide UI for selecting directories etc.
So catting a file is stupidly clumsy so you are pretty much forced to create an alias to make it tolerable, but of course you will normally not have created that alias and typing in the whole command without the alias is a big pain, so chances are you simply won't carry out the task that the Unix guy would have already completed while you are still trying to find a place to store your alias permanently.
And why does working with Microsoft products always turn out to be just like this?
Ahem. The GP showed you how to list the *built-in* aliases. That's right, cat is a built-in alias for Get-Content. So basically you just *assume* that Microsoft products are "just like this". You fail.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*