Ask Slashdot: Moving From *nix To Windows Automation? 427
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?"
WMI (Score:5, Informative)
Re:WMI (Score:4, Funny)
WMI is great. If you liked the complexity of CORBA, COBOL, VB Script, and the syntax of SQL, you will love WMI.
What is this "Powers Hell"? (Score:3)
I would like to subscribe to your newsletter.
Try the veal.
-- Terry
Re:WMI (Score:5, Funny)
WMI is really powerful, I only wish the documentation was better. You can do some really powerful things with VBScript and WMI.
Wait a second, something's not right here...
Linux has well-known utilities that everyone is familiar with?
Windows has powerful tools with terrible documentation?
I AM IN BIZARRO WORLD!
Learn VBScript (Score:3)
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.
Re:Learn VBScript (Score:5, Informative)
All Windows automation that you might want to do is exposed through a COM interface and there is no programming language targeting the Windows platform that doesn't include support for COM
What about languages that aren't so much targeting Windows but just barely support it?
On a personal note, when decided to switch from command scripts to a programming language, I was afraid that it would be hard. But it turned out that most things are actually easier (if at times a bit more tedious) and it's a lot harder to shoot yourself in the foot in most of them. At the very least you'll never get errors caused by the unpredictable script syntax again.
BASH is basically turing complete. Also, "[...]at times more tedious[...]" is the issue. I do 95% of my work in a Windows environment and a lot of times I long for the simplicity of *nix. Most of the time in Windows I feel like I'm fighting a huge and complex system, trying desperately to make it behave in a sane and rational way in order to produce the desired output. In the *nix world at least it's just my code I'm battling with, not the entire OS and ecosystem. But hey, maybe some people actually like a world where all systems communicate using XML and where character encoding is "enicode" yet in practice can be pretty much anything as long as the marketing division can claim it's all unicode because technically the operating system uses unicode internally...
Re: (Score:3)
Unix toolkits have been adapted to Windows on numerous occasions. This story is littered with descriptions and mentions of various toolkits for languages like Ruby and Python. Heck, Perl has long had a variety of modules for approaching Windows. And Cygwin is shot down right in the summary. Then of course there's Services for Unix, and let us not forget ye olde MKS Toolkit.
The problem is that none of them really fit Windows all that well, although I'm sure you can accomplish quite a bit in most of them. I'v
Re: (Score:3)
not everything, VBScript handles optional arguments, Variants and SAFEARRAYS better than JScript. All key differences when talking to COM.
Or... (Score:2)
Tons of options (Score:4, Interesting)
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.
Assuming you absolutely have to use Windows... (Score:5, Interesting)
Re: (Score:3)
Also VMware is another tool good for setting up multiple "clean" systems for testing.
Re: (Score:3)
sqaforums.com - look up Quick Test Pro and get to work. Everyone talking unix is talking nonsense. If you're in a Windows environment, you work with that. You go in talking unix stuff and you're likely to get fired.
Re: (Score:2)
Embrace the Dark Side (.net) (Score:5, Informative)
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.
Re: (Score:2)
PowerShell supports remoting now which is nice.
Re: (Score:3)
I used remoting for some stuff, but for some reason, psexec just worked easier. Plus it was easier to specify a user on the command line. I know, I could have done it with config files but when I wanted to do just a one off dos command, it was just easier.
Re: (Score:3)
There is a lot of power in PowerShell remoting now and its easier than ever to use now.
Get-Content .\computers.txt | %{ Invoke-Command -ComputerName $_ -AsJob -ScriptBlock { gpupdate /force } }
This works great for simple stuff. The commands in the -ScriptBlock are ran on the target computer. The -AsJob is not needed, but it basically multi threads the command. Running it on every computer at the same time instead of one at a time. You have to use get-job and related commands to check up on them, but its
Re: (Score:3)
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.
So... you built SSH for your current Windows setup, in 3 months. I'm glad *nix comes with that little gem so that each IT department using *nix doesn't have to roll their own (like you had to on Windows). Let's hope your program is well documented, and works easily after the next Windows revision...
I'm glad you were able to hack together your own solution, but wouldn't it be great if MS gave you those options at the CLI and a remote command line interface out of the box, instead of requiring you to bui
Re: (Score:3)
Note that you don't need C# to deal with .NET and related stuff. IronPython [codeplex.com] can use anything from .NET directly just as well, but also has many stock Python modules available. And it might be more familiar to someone with Unix background, and its dynamic nature is better suited for scripting tasks typical of automation.
There's also IronRuby [codeplex.com] if you prefer the language.
...should not dos when it comes to Windows... (Score:2)
I see what you did there.
PowerShell (Score:2)
By far your best option. It can take a while to learn though. SharePoint and Exchange use powershell as their main interface for scripting.
this is a question more for stackoverflow (Score:5, Interesting)
http://stackoverflow.com/ [stackoverflow.com] has experts that go there just to help with questions like this.
Re:this is a question more for stackoverflow (Score:5, Informative)
I'd also recommend having a Linux box; you can work in a familiar environment, then share out batch scripts you write via Samba -- read-only for binaries dirs that don't mind being unable to write out config files; writeable (but perhaps not listable) for a centralized location for saving off output from your various scripts, and so forth.
VBScript and/or PowerShell (Score:3)
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.
Re: (Score:3)
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.
You don't need to use VBScript with Windows Scripting Host (which is what that thing is called). It also supports JScript out of the box, and if you value your sanity that's what you should use. It's not 100% conformant ECMA-262 implementation, but it's pretty close, and either way it's a much more powerful and readable language than VBScript.
The general problem with WSH is that it's COM-based. If software you automate exposes COM interfaces (e.g. Visual Studio), then it's all good. But newer stuff often on
Re: (Score:2)
ColdFusion integrates well with MS products (Score:3)
Can't beat the price.
Best practices are best practices (Score:3, Interesting)
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.
Nice Theory, Not Practical... (Score:3)
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
Re: (Score:2)
Let me translate the /. replies so far... (Score:2, Informative)
"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 automation for automation (Score:2, Informative)
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.
Re: (Score:2)
Opsware (now HP Operations Orchestrator) is just awesome. Besides lots and lots of plugins and templates it has a very cool feature which allows you to create a new workflow item based on a web service signature (WSDL).
Powershell (Score:3, Insightful)
OLE Automatisation (Score:3)
One possible way is OLE automatisation, but be prepared of the horrors of it.
Re: (Score:2)
OLE Automation [wikipedia.org] is a set of general-purpose scripting extensions on top of COM - defining various interfaces that permit dynamic dispatch, RTTI and other such things. It doesn't actually have anything to do with automation as such, except that it used to be the preferred way for applications to expose automation APIs should they have any - so whether there are any "horrors" involved or not, or whether there is any support at all, depends entirely on the application.
This is now superseded by PowerShell, in an
Python? (Score:2)
With the win32api module, can do Windowsy stuff, and you can transfer all your python skills from your Unix days. You do have Python skills don't you? Well, get some.
There's a native port of Python so no need for cygwin.
Don'ts (Score:5, Informative)
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.
Re: (Score:3)
SharePoint 2010 can be automated quite nicely in powershell. Thanks for the insight though.
I have to promote Microsoft products... (Score:5, Funny)
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 and other tools (Score:5, Informative)
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 [microsoft.com]
WMI diagnostic utility: http://www.microsoft.com/downloads/en/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en [microsoft.com]
gplogview: http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=BCFB1955-CA1D-4F00-9CFF-6F541BAD4563 [microsoft.com]
Windows SDK (including debugging tools for windows): http://www.microsoft.com/downloads/en/details.aspx?FamilyID=35AEDA01-421D-4BA5-B44B-543DC8C33A20 [microsoft.com]
ollydbg: http://www.ollydbg.de/ [ollydbg.de]
sysinternals suite: http://technet.microsoft.com/en-us/sysinternals/bb842062 [microsoft.com]
Windows Management Framework: http://support.microsoft.com/kb/968929 [microsoft.com]
WDK: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff [microsoft.com]
WAIK: http://www.microsoft.com/downloads/en/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en [microsoft.com]
Windows 7 SP1 WAIK supplement: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0AEE2B4B-494B-4ADC-B174-33BC62F02C5D [microsoft.com]
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.
Python (Score:2)
I tend to do this king of stuff (automated test harnesses) with Python (equipped with necessary platform-specific libraries). Naturally, this is Windows so COM and WMI are your friends. Note that IPython makes for an excellent shell for trying stuff out. I tend to go back and forth between Linux and Windows and Python definitely is a transferable skill.
What versions? (Score:2)
Opalis (Score:2)
Have a look at Opalis, which has been acquired by Microsoft and is now part of the System Center suite. It is a very interesting runbook automation environment with plugins for most Windows-related tasks. It is graphical and pretty user-friendly, and if something cannot be done natively you can extend it with Powershell.
AutoIt (Score:2)
AutoIt is brilliant, I've had a lot of fun with it. Some people like AutoHotKey, but I can't get used to the syntax. I'm dabbling with MacroMonkey which looks like it can do a lot of the same stuff with a better language (Lua) but not as well-developed a library and nowhere near the same community as AutoIt (although there are some very abrasive personalities on the forum).
It is not about scripting alone (Score:2)
The problem is that Windows la
Re: (Score:3)
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
This is covered quite well (Score:5, Informative)
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.
Re: (Score:3)
while read server; do ssh $server 'apt-get upgrade' || break; done < server-list.txt
Poorly planned project (Score:3)
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.
Ruby, Win32OLE (Score:3)
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.
Comment removed (Score:3)
Re: (Score:3, Informative)
Re:Don't do it... (Score:5, Informative)
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 [activexperts.com]. 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 [sapien.com] 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++ [notepad-plus-plus.org] 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!
Re:Don't do it... (Score:4, Informative)
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.
Re: (Score:3)
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 upg
Re:Don't do it... (Score:4, Insightful)
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.
Perl, ReXX? (Score:3)
There is likely to be a reasonable selection of earlier work available in both, even for Windows.
Re:Perl, ReXX? (Score:4, Insightful)
When in Rome, do as the Romans do.
He was asking about Windows server administration, and PowerShell is the right way to do that.
For most new Microsoft server products, the script bindings are only available for PowerShell (in the form of snapins or modules). Many third-party vendors are releasing products that are PowerShell only. It is also the only shell that can call all mainstream APIs (COM, WMI, WinRM, and .NET).
Perl specifically is one of the worst possible options for Windows scripting. It is a text processing scripting language designed for Linux, where most applications and even system APIs are text based. Windows mostly uses object-oriented binary APIs. Very few Microsoft server products have text-based command-line tools that could be automated with Perl.
Suggesting Perl for Windows automation is a bit like trying to script Linux with VBScript. Does that sound like a good idea to you?
Re: (Score:3)
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 depen
Re:Don't do it... (Score:5, Funny)
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.
Re: (Score:3)
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...
Re: (Score:2)
Yeah, on linux it was:
Day 1) Find autoexpect, leverage that with some bash/perl/python/tcl etc foo
Day 2) Done
Re: (Score:2, Informative)
Mouse click away you say? AutoIt [autoitscript.com]
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.
Re: (Score:3)
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 programmatic
Re: (Score:3)
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
Re: (Score:3)
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
Re: (Score:3)
Re: (Score:3)
Actually, I was referring to this text.
Re: (Score:3)
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.
Re: (Score:2)
Just don't. [/notsarcasm]
FTFY! ;-)
Re: (Score:3)
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 sp
Re: (Score:3)
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 fo
Re:Don't do it... (Score:5, Interesting)
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.
Re:Don't do it... (Score:4, Insightful)
Re:Don't do it... (Score:5, Interesting)
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.
Re:Don't do it... (Score:4, Informative)
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.
Re:Don't do it... (Score:5, Insightful)
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."
Re:Don't do it... (Score:5, Informative)
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.
Re:Don't do it... (Score:4)
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.
Re: (Score:3)
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, c
Re:Don't do it... (Score:5, Interesting)
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 [microsoft.com], and Cmdlet Development Guidelines [microsoft.com].
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
Re:Don't do it... (Score:5, Interesting)
Re:Don't do it... (Score:4, Insightful)
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."
Re: (Score:3)
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 l
Re: (Score:3)
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.
Re: (Score:2)
AutoIT [autoitscript.com] gives you the flexibility to make Windows your bitch.
HEX
Re:autoit- THIS! (Score:2)
Re:a VM... (Score:5, Interesting)
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.
Re: (Score:3, Funny)
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.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
Re: (Score:2)
None of the "enterprise class" applications I use have a hope of that unless the vendor undertakes to rewrite them from the bottom up.
Re: (Score:2)
Re: (Score:3)
http://img546.imageshack.us/img546/2518/imageinf.jpg [imageshack.us]
Re:Powershell is a Winner (Score:4, Insightful)
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?"
Re: (Score:3)
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.