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?"
Dont:
Windows Automation
'nuff said
Your answer to everything is WMI. Just start command prompt, type :> wmic And voila, you are ready
Your best bet is to learn Windows Powershell (ships by default with win7): http://msdn.microsoft.com/en-us/library/aa973757(v=vs.85).aspx
Its scripting language is built on .NET and provides access to all of the power and flexibility available in the .NET framework. You can also write your own commandlets/plugins in C#/VB.NET to extend Powershell's capabilities.
not too many options - Windows PowerShell, that's about it.
And why not? Powershell is perfect for the job.
Is it?
> what approach and methodology is best for developing, say, the automation required for a test system?
Install Linux in a VM, and do all the automation from there.
Then you can eventually migrate to removing the Windows machine and running Linux directly on the hardware.
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."
Windows automation now-a-days == PowerShell. It is actually powerfull and pretty well thought through.
Hmm...
If you really must, I guess really the only thing Microsoft is trying to push now is Powershell. It works, but it is an abomination.
You'd be better off getting familiar with Boo (http://boo.codehaus.org) or Ruby or Python/IronPython, imho.
Boo is a .Net scripting language with lots of Python-isms. Its scripts are compilable to .Net exes.
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
autoit or powershell are about as good as it gets for windows automation.
C++ is much faster than all that stuff, I've used it for years - it's a synch! Top Tip!
The purpose of existence is to make money.
Mod parent up.
Powershell is probably your best bet.
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
I see what you did there.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
Do my job for me! Waaa!
If you really want to do an outstanding job, bring all the experience you have with Unix/Linux, but surround yourself with all the windows technology. I've found in the past that when I switch different environments and try to bring the same technology to the new environment, I miss out on all the advantages (and yes disadvantages) of the technology. I've been working in Unix since the 80's and Linux a long time too, and there was a time when you could not even get me to look at a windows environment. But those days are long long gone. The .Net environment is really very good. I think you'll enjoy it, if you give it a chance. Good Luck!
By far your best option. It can take a while to learn though. SharePoint and Exchange use powershell as their main interface for scripting.
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
That is all.
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
I would have said Python alone, which has some pretty good cross-platform support, but IronPython also has access to the entire .NET platform.
And remember why you initially did your automation on *nix based platforms...
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.
I've been down this road. vbscript is more than a little annoying, but you can count on it being there, and it knows about COM (which you'll also enjoy). Good luck.
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.
Unless 100% of the applications that you need to integrate into your automation are driven by CLI or some kind of well-defined API, you'll be out of luck.
Windows isn't designed for automation. It's designed for moronic pointing and clicking.
Parity: What to do when the weekend comes.
"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
Yeah, on linux it was:
Day 1) Find autoexpect, leverage that with some bash/perl/python/tcl etc foo
Day 2) Done
ymmv
Just don't. [/notsarcasm]
FTFY! ;-)
StarTrekPhase2 - The Five Year Mission Continues!
Got into Autoit on a recent project. Definitely a good implementation. Did what I wanted completely. I was calling Autoit into and out of Maya (3D) scripts, chaining it all together. Was able to wait and timeout on specific Maya exporter dialogs and trap contingencies. There was a little funny business with different ways of accessing the windows controls, but not too hard, just ganked code from some demos.
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.
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'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.
Lets look at the situation. You have the Unix shell (C, Korn, Bourne, Bash, etc), designed over long periods to offer universal functionality and complete environmental control. You can control processes in detail. You can integrate seamlessly and universally with every application on the box, and are given more control and more options than the graphical user interface. The shell scripting languages offer logic and control structures consistent with Turing Complete languages. There is nothing equivalent, or even close in the windows world. There are some 3rd party applications that may attempt to do scripting, but they are all after the fact. Windows was never designed as a 'back end' system. Their offerings offer limited functionality, since its all after the fact. Part of the issue is that its almost universal that every application that has a graphical user interface in Linux or Unix, also has a non-graphical interface integrated and designed as part of the application. Many windows applications don't have that functionality (all user control over the application is graphical, all output is graphical, except to very specific parts areas of the operating system, there is rarely any back-end command and control that a scripting language can do anything with). Shorter answer: you are going from a richly endowed system to a very sparse one. You are already in trouble.
Dos Batch Scripts (.bat & .cmd) SETLOCAL is your friend.
AutoIT (script gui programs!)
http://www.autoitscript.com/site/autoit/
Unix Utilities (deploy if you can)
http://unxutils.sourceforge.net/
Also remember that in dos: /i "thing I want to look for" *filenames*
find
works a lot like a weak version of grep.
Also look into windows powershell (I have not used it but the internet says it's awesome so it must be true.)
Also a lot of windows programs have command line options or programs you can leverage. You can build an entrire AD domain from the command line if you use the appropriate methods.
TURN BACK
(Sign you see in UK&Ireland when you get off the ferry on the wrong side - they drive on the left)
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
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.
I would like to die like my grandfather did - sleeping. And not screaming in terror, like his passengers.
Haven't used it myself, but I've seen it mentioned in regards to unit testing on windows - http://www.autoitscript.com/site/autoit/
Did I miss this in the comments or has no one suggested it? (perhaps it's not really geared for what you're doing)
I have zero experience with powershell, but it seems like you're saying it's a quick, painless solution.
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.
Why not give Opalis a try? It's actually really easy. PowerShell is more powerful, but it's not exactly intuitive.
http://www.microsoft.com/systemcenter/en/us/opalis.aspx
Good luck.
Are you talking about 2008 and Windows 7? Or do you need to go back to Windows 2000, XP, or even 2003? There are significant differences in the tools available based on the version (for example, powershell...)
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.
lucm, indeed.
Whatever you do, expect it to break on you because of: ...
1. Microsoft update
2. Adobe update.
3. Java update.
4. A field overflow deep within Windows.
5. Random licensing failure.
6. Some random app crashes.
7. Someone on the network updated their version of Word, causing your database access to fail.
8. Hackers.
9. Virii
And, it will probably takes weeks to find the problem and then get it working again, for a little while.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
http://www.csscript.net/
Is there a list of should and should not dos when it comes to Windows automation?
Yes.
1. Do not do Windows automation.
That is all...
That is all.
VBScript and "jscript", along with the Windows Script Host, are designed for COM automation. Most of what you need in that case can be found in the script56.chm file.
http://www.microsoft.com/downloads/details.aspx?FamilyId=01592C48-207D-4BE1-8A76-1C4099D7BBB9
Perl is not COM-oriented, of course, but can be adapted if you prefer. .Net is not primarily COM, so it doesn't make much sense unless you already know .Net and like it. Some have suggested WMI. WMI is not script. It's a set of classes that can be used through script -- typically used with VBScript. For most things other than hardware information, WMI is just a clunky, slow wrapper, while the syntax is ugly and unintuitive.
I've written complex tests (1000's of lines) in perl which run on Windows, Linux, AIX, and Solaris. In my case I'm both Unit testing software changes, and regression testing before submitting into fhe code base.
A lot of the tests at our company are written in perl because most of the perl code works on all the platforms we ship our product on. Most of our core product is written in C.
so that you can give yourself a pre-frontal lobotomy to bring yourself down to Windows level...
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).
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. 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.
The problem is that Windows lacks such an modular, abstract foundation. 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.
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.
I think, the question is not: How do I automate Windows? The question should be: What system should I use, which one is good at automation?
And the answer is definately Unix, not Windows.
Try REXX http://en.wikipedia.org/wiki/REXX
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.
Not quite: if you perform the second option correctly, the pain and misery will be over quickly. ;)
Powershell can be installed on XP/Server 2003 and Vista/2008 and Powershell V2 comes by default in Windows 7 and is a built in optional feature in Server 2008 R2, so it is available on all modern Windows OS'.
There is pretty much nothing you can't do in Powershell. It has an innovative object pipeline system and excellent syntax. The learning curve is high but what powerful programming language doesn't have a high learning curve?
Want to construct a 'magic packet' and send it over the network? No problem: http://powershell.com/cs/blogs/tips/archive/2011/02/24/sending-magic-packet.aspx
Want to automate SharePoint? http://www.u2u.info/Blogs/karine/Lists/Posts/Post.aspx?ID=9
Want to automate Exchange? http://technet.microsoft.com/en-us/library/bb124413.aspx
Want to read a binary file? Get-Content -Path C:\binary.file -Encoding Byte
Want to connect to a web service? http://technet.microsoft.com/en-us/library/dd315258.aspx
Want to query a SQL database? http://thepowershellguy.com/blogs/posh/archive/2008/02/28/listing-all-the-databases-from-a-sql-server-from-powershell.aspx
Want to construct a GUI? http://technet.microsoft.com/en-us/library/ff730941.aspx
Want to convert a bitmap to a GIF? http://blogs.technet.com/b/heyscriptingguy/archive/2010/07/05/hey-scripting-guy-how-can-i-use-windows-powershell-to-convert-graphics-files-to-different-file-formats.aspx
Want help from the Powershell community? http://www.powergui.org/forumindex.jspa?categoryID=55
Want to search a repositiy of pre-made scripts? http://poshcode.org/
Need help with a script? http://www.powergui.org/forum.jspa?forumID=165
And the list goes on and on and on and on....
I think I might look for another job...
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.
There are a number of responses above with varying degrees of M$-enlightenment (thalakan's being the most professional); however, it's not entirely true that Windows was designed exclusively for point-and-click administration. That's only true of the GUI shell. Windows was *designed* to be administered by *compiled* code. Preferably C++, which is the only thing that can deal directly with the shitty disaster that is the Win32 codebase without making things worse. Everything else is a shim over the Win32 nightmare, which is still the "core" of the operating system. So, everyone saying "you're just fucked" is in some sense accurate, albeit not precisely correct. The whole OS should have been refactored starting in 2003, when Microsoft pretended to be interested in security. It wasn't, so here we are.
win32api provides COM interfaces to just about everything on Windows. But you will need WMI too so make sure to get Tim Golden's WMI module. And if you need to do anything with .NET, there is IronPython: same language, just different vm underneath.
If you do use WSH (Windows Scripting Host) do not be tempted by VBScript. Too many dead ends and limitations. Use only JSCRIPT which is basically a slightly older version of Javascript. Use Javascript and WSH instead of batch files to glue things together.
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.
Posted as me. 'Cause I care.
The soylentnews experiment has been a dismal failure.
MS Exchange tells you what to do with it in the name - swap it for something that works. That said you are stuck with it so the way to deal with this moving target (new release announcement - something that should have been there in the first beta and we've pretended it's been there all along now works!) is to stick to where it's behaviour is bolted down to standards outside of Microsoft and you'll know a patch or upgrade won't break the part you are talking to. Sharepoint is almost as is somebody finally decided to do a decent FTP replacement but was driven to drugs halfway through - with that you'll have no choice but to chase a moving target.
As for the language - the developers where I work have been stung by VB changing into vastly incompatible things to the point where there are still production systems running Win98 (although part of that is hardware compatibility with A/D converter cards). They moved to python to get away from needing a pile of different VB environments. That's one choice but there are plenty of other cross platform choices. If something has libraries that do most of what you want already that's probably the language to go for.
Fanboys that have never touched MS Exchange apart from fetching mail from Outlook will probably flame me for the first line. Instead take a deep breath and google for the new feature list of each of the last few versions of MS Exchange which will give you an idea of how much was missing from the previous one. Getting a proper backup you could use for a bare metal restore or even full mailbox recovery on MS Exchange used to be impossible without shutting the entire creaking structure down for the duration of the backup. It tries to do everything so there is no single thing that is like it - but as far as SMTP goes there are probably well over a dozen better solutions.
Once you have it you are stuck with it and have to change the way your organisation works to fit in with the way MS Exchange operates. When that has happened there is no going back without breaking a lot of things.
Powershell is actually very powerful as it can extend or be extended by the .Net framework.
Excuse me while I shudder.
Have you got your LWN subscription yet?
Since you mention testing, I thought I should at least mention NAnt. I run a number of build servers under CruiseControl.Net that makes calls to NAnt. The NAnt scripts make calls to thing like NUnit, MSBuild, devenv and FxCop. This automates our continuous integration and release builds. There are other tools that can be thrown in like NCover. I also do automated Flex builds, but that is under Hudson. This is on Windows Server 2003 and 2008 in 32 and 64 bit versions.
As others have mentioned, PowerShell is very helpful as a replacement for your other scripting tools. Personally, I still use Perl.
It's not so bad if you make use of the Sharepoint Client Object Model that comes with SP 2010.
Use the Javascript version (and JQuery) to do whatever you want on an SP page, and use the .NET version of the Client Object Model to write IronPython scripts that integrate it with other systems.
Yes. How is it not?
I know right? It's much better to hook together a bunch of command-line utilities with arcane syntax that pass bytes between one another.
run away as far as you can, don't waste your time with that system! have you been demoted or something?
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.
Most Microsoft products from the OS itself to server software to office apps expose COM Automation interfaces. COM has been the standard for extension and automation on Windows for a long time. NET is creeping up there but COM interfaces are always guaranteed to be available from Windows Explorer to IE to Excel to Exchange. Much of the time the .NET interfaces are just wrappers around COM interfaces., You can use any language that can bind to COM objects - Python for instance with the win32 modules, or PHP. Activestate also provides COM binding libs with their Perl and other scripting language distros. As for language choice, well funny enough I always found Visual Basic 6 to be the fastest and easiest way to work with COM.
Muppet Show > Monty Python
STFU, nobody asked for your analysis. There isn't anything wrong w/that sig.
Friday night and no date again? Wonder why?
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.
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
Is there a list of should and should not dos when it comes to Windows automation?"
Am i the only one who had to look twice?
And is the end of the world near, or did the random quote generator resume only to come up with like 5 pages of craziness?
DBD::WMI
Win32::OLE
Win32::WMIC
Win32::GuiTest
Win32::TieRegistry
Win32::Unicode
Win32::API
Inline::C
Perl::Dist::WiX
Win32::MSI::HighLevel
http://search.cpan.org/search?query=win32&mode=dist
http://roth.net/
http://books.perl.org/books
Perl Books - Book: Perl for System Administration
http://www.perl.com/
http://strawberryperl.com/
http://www.cava.co.uk/citrusperl/strawberry.html
google:// site:http://perlmonks.org/
Since I still have to support Windows XP systems, I use what will work with them. I also don't like to have to install any additional run-times. You can accomplish almost anything with a combination of Group Policy and Visual Basic scripts. I would also highly recommended AutoIt, which i find to be a very helpful tool, especially when trying to automate anything that has a GUI. Finally I would note that what you used to MAN, now just look up on MSDN. I just use google as follows: "msdn [terms]".
You have an anger problem. Seek help.
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!
No, you were trying to make the point, so the burden of research is on you. Please, enlighten us.
All my liberal friends think I'm a conservative, all my conservative friends think I'm a liberal.
For those things where clicking is unavoidable, MJT Macro Scheduler not only allows you to automate it, but to run in client/server mode, so you can have clients that take macroing commands from a central server. This Enterprise version isn't exactly cheap, but it can be a great way to get around the most aggravating repetitive tasks for which scripting doesn't work.
3) Profit!
For normal Windows stuff (including COM/OLE/whatevertheheckitscallednow automation) you'll definitely want Mark Hammond's py2in32.
Even so, you'll be scratching your head and reinventing a few wheels if you want to do automation of arbitrary preexisting programs.
Last time I did any Windows automation (which was a long time ago because I stay as far away from windows as possible), I used the PyWinAuto module, which lets you interact with other programs quite handily from inside your Python script.
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
Obviously all women require that sort of advice from men, so we can hope to be "proper women".
Get over yourself, indeed!
Caveat Utilitor
Try it. The PyWin32 mailing list is also very helpful.
> so what approach and methodology is best for developing, say, the automation required for a test system?
Suicide?
RUN
RUN like the wind
Get as far away as you can get.
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.
Now you made me sad :(
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.
Uh... bash/csh isn't pre-installed on any Windows. Pay attention... OP is moving to a Windows environment.
Why
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.
Otherwise, you're looking at VBScript or batch scripts.
Powershell handles WMI - http://technet.microsoft.com/en-us/library/dd315295.aspx
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.
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.
Application called "Scheduled Tasked" (usually in Program --> Accessories --> System Tools) is equivalent to setting Cron Jobs.
Group Policy (Active Directory and Appropriate package must be installed) can distribute and run your scripts (say for users at login).
Backup frequently, being sure to include System States.
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 your friend.
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).
I don't know why you think that Cygwin cannot deal with Windows type stuff like Exchange and Sharepoint. You're a little vague as to what you need to do with them. I use Cygwin while on Windows and find it can do just about all I want to do.
PowerShell is great for this type of automation, but for GUI automation you need to do all scripting to do it with PowerShell (at least the last time I checked - I did find some snap-ins for GUI calls, but never anything that records them as PowerShell calls). If that is OK, great, but if you have access to the API a more modern record and playback (+ maybe a hair of customization - like for unique key names - our internally built software adds a number when using these automatically) that relies on events to the widgets rather than mouse clicks may be a better route. Our devs said the record and playback was trivial to add to .NET and Silverlight clients (we support some phone clients and HTML5 was too immature at the time - maybe after it gets ratified in a couple of years... - our other client is java based).
Don't be shy. Tell us how you really feel.
In what way is any of that more powerful than what could have been written as just regular commands? PS is just a new locked in way of doing the same old shit. I'll pass.
PowerShell is nice but it's a single purpose tool. Arguably this is a good thing but as you can do the same things with Python (including working with WMI etc.) I prefer to use that instead.
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.
I use puppet myself and it is a great !@#$ing tool but as far as your yum question, I don't know what the answer is but on debian, ubuntu or anything else that uses the dpkg system, the answer is this
dpkg --get-selections package-name
This will return the package name you searched for, tab separated by it's install state. i.e. deinstall, install, hold, etc. Fairly easy to program to get the status of whether or not a package is installed.
Interesting, reminds me of ARexx, except that PowerShell came 20 years later.
3) Profit!
Indeed.
The Linux-based servers and the legacy Tru64, AIX servers I have to maintain pay my bills. Thanks Unix!
I'm about 2/3 Windows and 1/3 Linux sysadmin. I've done perl, bash, DOS batch, vbscript, Powershell (etc). I honestly feel much more power over my enterprise with the Windows tools than I do Linux. It's probably a combination of a couple things:
Active Directory for single-sign-on (no authentication) admin access to all my boxes, by just opening one command prompt / Powershell window with Run-As and my admin credentials. So in one window I can do anything to any of our 1500 Windows servers in my enterprise. I don't have to mess with sending alternate credentials to each server, or accepting/caching SSH keys, or any of that.
While archaic at times, the structured availability of all the WMI classes is SO powerful. While similar in ways to the /proc system, I find a lot more value. And you're not grepping config files, where unexpected content or typos will mess you up.
(Oversimplified) one-liner Powershell to get the BIOS versions for all your servers? $servers just needs to be an array of computernames. Can be populated from anywhere (a database, a text file, or Active Directory query)
gwmi win32_bios -computer $servers | select __SERVER, ReleaseDate | sort ReleaseDate ..love it.
Since you already knows how to do it on a *nix computer I advice you to:
1. Buy a Slackware Linux 13.37 CD
2. Install Slackware on your windows computer.
3. Do as you did when doing automation on a Linux computer.
4. Profit from your old knowledge !
Never change whats perfect.
You're going to be *that* guy when you're 58, still clinging to your outdated philosophies, hanging on for just another couple years before you can retire and get away from those young punks.
Quick Test Pro really is a good product, but it's really expensive too. If you want a free (if not Free) alternative, look into AutoIt [autoitscript.com]. It has a SciTe editor that comes with it, which can help with setting up automation by recording. (Never use recording, on any GUI automation system, without at least looking over the script; but it gives you a nice baseline to work from.)
(T>t && O(n)--) == sqrt(666)
You are just upset that he was right.
There is a free limited version of the TakeCommand (just console, no gui, and no script interpreters) but including their very nice extentions to the bach language
I may be out of fashion, but love to script windows in rexx, and the win32 ibm code base its now free and open source
For frecuently needed windows specific, recurrent, and platform idiosincratic tasks, nothing beats the ease of use and flexibility of AutoIT (or AutoHotKey... both freeware)
Using the Console2 project in sourceforge you can have a free tabbed terminal window
Or just buy the full TakeCommand (some people here use radmin instead)
Having done this myself (a bunch of Windows servers that were kept around because they were needed for a particular proprietary app), the right answer that works is actually Cygwin. With sshd on every box. It's the only halfway sane way.
If you're not allowed to install Cygwin, you're working with one hand tied behind your back. Get your resume in order.
The important thing here: Keep a local Cygwin repo, in which you copy all those downloaded files to an accessible place on your network. It is less important that the Cygwin installation be up to date than that it be consistent. You can have DLL Hell with multiple versions of cygwin.dll happening to be present on a box ...
And not surprising.
First, get into VBScript AND VBA. I think SFU 3.5 runs on Vista/7, and Powershell is just very useful. But VBA and VBS will et you do plenty.
Trying to use Java and Javascript will frustrate in many ways, but might be helpful.
It sounds like you are trying to develop test utilities for your development. VBS/VBA are very helpful here. You could develop an Excel sheet and use VBS to create SMTP messages and drive mail to an Exchange server pretty easily. And use it to pass messages to your various platforms, including Sharepoint if someone has been listening to Microsoft consultants again. It happens even in the best organizations, don'te be embarassed.
I work with a creative guy that uses VBS to create messages for a test financial system. He's got it down so he can create 100,000+ messages that fire all errors and encompass all desired scenarios, with unique sample data if desired or a standard data set. These include ASCII, EBCDIC, packed binary/bcd/decimal/whatever- the-programmers-are-calling-this-week, BLOBs, hex, and encrypted strings. When the developers tried to do this themselves, it took them 4-5 manhours for one test, and they test 20-30 times a day at some points. He satisfies their demands in 5-10 minutes, submits via HTTPS PUT, and then parses the results and sends this back to them all in a half hour. They loathe him, because he demonstrates their futile efforts to solve the problem the same day they declared the problem solved, usually before they can schedule the celebratory luncheon. Fun to watch, since it's not my group involved...
Oh, and he's porting this to a Java app so it can be given out to the development teams and deprive them of another excuse to drag out the process. There is nothing about this development process that offshoring hasn't made substantially worse by every measure. Well, maybe the celebratory luncheons are more fun...
deleting the extra space after periods so i can stay relevant, yeah.
The most important part is error correction. There are two primary methods in the windows automation world.
In the Gibbs method, you smack the low-paid butt monkey on the back of the head sharply when he does it wrong.
In the Hill method, you give the butt monkey several quick slaps to the top of the head. This works best with older balding butt monkeys.
For the more advanced, there's also the Blackadder method where you devise a cunning plan to avoid being forced to go catch bullets in the first place. That one can work for a while, but tends to fail in the end.
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.
On second tought, if you have the money:
- the best native scripting alternative in the same range (from win95 to win7) probably will be the polar engineering vba
- and again, in the same support range (from win95 to win7) by far the best option for custom binaries its Delphi (7 will do) or maybe powerbasic if you only care for api and com integration and dont need rad
yes, you were being a cunt. good job on that but we're talking powershel here, so GTFU btard.
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.
Autoit, free and can compile it's scripts to exe if you want. IT can even interact with GUI only probrams unattetnded
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). Perhaps a better example would be getting the current swap usage... No that's 2 lines using SSH. Maybe determining the list of software updates available on our entire network of Linux servers? 1 line to set sh as the shell, 1 line to read the list of servers from a file, 1 to start the loop, 1 to execute SSH with a yum list updates, 1 to accumulate the output, 1 to close the loop, and 1 to use mutt to email me the file. 7 lines.
How exactly do you see Windows updates for all packages again? Oh, right, it's not a feature. Yawn. Call me when that toy becomes as powerful as the Linux/UNIX tools we've been using for decades. And doesn't require a huge set of frameworks for basic tasks.
> What the heck does it mean that PS can extend the .Net framework, and itself be extended by .Net
Using .Net you can create commands (CmdLets) which can then be used in Powershell scripts. It is therefore pretty easy to extend the built-in CmdLets by adding something customized for your needs. You can even dynamically create data types in Powershell using C# syntax, and then use the objects in the scripts.
On the other hand you can invoke Powershell from a .Net software to use its powerful features. Many tools nowadays in the System Center suite are built using Powershell, and only the GUI is done in C#. Powershell is more fluid and flexible.
Most enterprise software on Windows now comes with a .Net SDK; being able to interact with those libraries in a scripting language is very convenient.
> To be more convincing, I would like to see some example commands showcasing the power and flexibility of PS.
Just an example, using PowerCLI (the VMWare Powershell extension), if you want to get the list of VMs on all the hosts managed by the VC to which you are connected, you simply use this command:
Get-Hosts | Get-VM
and if you want the output in a nice CSV file that you can then import in a DB or open with Excel, you type this:
Get-Hosts | Get-VM | Export-Csv -path c:\MyFile.csv
Now with this short one-liner you can get you VM inventory; imagine what you can do with a whole script. The piping is extremely powerful, the engine will figure out if you pass a property, an object or a string. But you can also use enumerators (such as For Each) or use a Perl-like notation (such as | % {} instead of For Each).
> Quite honestly, your post just seems like a bunch of buzzwords
The original question was about automation on Windows; I think Powershell is a perfect tool for that kind of task so I had to disagree with the guy who said it was an abomination. When you know how to use it, it is very powerful and convenient. It feels a lot like Perl, but with some features that are specific to Windows.
lucm, indeed.
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!
"Arcane" is a term that is only ever used to describe a non-Microsoft OS
LOL As if undocumented registry hacks and tricks like "psexec \\computer cmd /c echo . | wmic bios get serialnumber" are normal. Why does wmic still require ghostly input?
I will just had the freeware servers freeSSHd and freeFTPd for a perfect scripted remote administrated windows on the cheap
http://www.freesshd.com/
Or for the cygwin based mobassh for a more linux feeling
http://mobassh.mobatek.net/
> Call me when that toy becomes as powerful as the Linux/UNIX tools we've been using for decades.
Well don't get involved in a thread about automation on Windows if you are not interested. Showing your incredible SSH skills and your disdain for Windows is definitely impressive but it is also off-topic.
But one thing is sure: as soon as I can get a client to have a budget so someone can send himself files with mutt I will contact you (I hope they won't pay by the line otherwise it will be a bad deal for you with your powerful 7-liners).
lucm, indeed.
As soon as you mentioned Exchange and Sharepoint, you're fucked ... the only way you could make it worse it to mention Project. Crap software written by large crowds of overpaid geeks who don't respect their company anyways. Get a grip. If you're 'next project' is M$ then don't come whining to the crowd. Suck up and handle the shit in your britches
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?
Yeah, that's great as long as you and everyone who ever uses your output forever uses .NET, eh? Locking into a single product from a single vendor couldn't possibly create problems. Although really I guess you're locked in to running on a single platform using a single utility from a single vendor -- the SAME vendor, haha -- so it's not too much of a jump.
To be fair, Powershell isn't pre-installed, either. ;)
Powershell is however "perfect" for the job because half of anything you do on Exchange 2007 or 2010 requires using the thing anyway, and while clumsy as hell, it is miles above using *vb* to do anything.
Quo usque tandem abutere, Nimbus, patientia nostra?
well, let's review. You've done automation with Unix before ... check ... So I'm guessing your not a complete moron. Now you are switching to Windows. Wow!!! I don't think any of us has done that. Another project on a different OS?!?! you didn't!! ... There's no *way* you're doing projects on one OS and then switching to another!!! Just wow!! ... oh ok, all kidding and bs aside. If you're for real, do a google search and figure it out. If you're just a fucking shill then ... ... ... just sayin
Yeah, XML is really proprietary, impossible to decipher without reverse engineering; the worst format for interoperability.
Actually, if you are running exchange 2008 or later then you have to use powershell - the wmi hooks for vbscript just don't exist for later versions of exchange. You can get powershell for XP but you have to be on SP3. Powershell does have its quirks though, the one that particularly catches me is trying to reference component of an object in an argument list. Doing a GUI is an exercise in patience. If you have done some perl programming then you should be reasonably comfortable with Powershell.
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
...so you can write scripts that depend on the format and have them work in 2032.
Just saying.
-- Terry
I would like to subscribe to your newsletter.
Try the veal.
-- Terry
I highly recommend writing IronPython scripts and having them regular run using the Windows Task Scheduler. This has worked remarkably well for us.
I got laughed at the first time I suggested it, but now my IronPython scripts are well in demand for such tasks.
Y
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
[Disclaimer: I have only a little experience with Powershell, and certainly don't use it on anything like on a regular basis.]
It's not different in the sense that they are little programs that you write and primarily interact with from the shell. Where the big difference comes into play is that when you pipe one cmdlet to another, what gets piped is objects, not text.
This has a number of useful benefits. First, they are strongly-typed. Second, no parsing is needed on the receiving end -- and this means fewer possibilities for introducing bugs. (E.g. how many times do you see people actually use 'find ... -print0 | xargs -0' instead of just 'find ... | xargs'?) Third, the scripts have access to .Net natively, which will give you way more than any shell script (though not more than, say, Perl).
I think a fourth benefit is most intriguing, though this is mostly speculation on my part. Lets say you have a shell pipeline 'foo | bar'. There are many times under the Unix way that the way you invoke 'foo' depends on what you want to follow it in the pipeline, but under Powershell it needn't. Why not? Take ls for example. Suppose that you wanted to list the files in the current directory, sorted by size (and say for the moment that ls couldn't do this by itself, so you want to send it to some 'sort'). Under the Unix way, you'd have to do something like 'ls -l | sort ...'. Note that you had to pass -l to ls. In the Powershell world, the ls equivalent I think just spits out a sequence of objects that represent files in the current directory. If you just type 'ls', by default it would just print the file name. But those other fields are still there for things later in the pipeline to access if they need to. So with my hypothetical example, you can eliminate the -l argument.
Bitter, overmuch? The problem could never be you of course...
Sorry, but bzzzzzt! The ninth circle of hell was the frozen lake, where traitors go. A three headed Satan frozen to his waist in ice, eternally gnawing on Brutus, Cassius, and Judas. Read an annotated version concurrently with a rhymed version of the Divine Comedy, or the original in Italian. It had a rhyme structure that's next to unrenderable in English.
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.
It's UAC. If you're in the Administrators or Domain Admins group and have UAC turned on, you're not *really* in that group. If you start your editor by right clicking it and choose Run as Admin (receiving the UAC prompt), the editor is now running with Admin/Domain Admin credentials, so you can edit that file as you see fit.
Just double clicking the file opens it as a normal user, without either of those groups, which is why you can't save over the top of it. If this really annoys you, change the permissions so another group you're a member of has rights to it.
I would add WinMerge to that as well - that's been useful a few times when exporting registry settings and the like.
NotePad++ is ALWAYS better than Notepad! :)
I am a viral sig. Please copy me and help me spread. Thank you.
cmd.exe has the most horrifying syntax and evaluation model imaginable. if you need anything more than a few lines of code, ditch it
Oh, it's not all that bad at all.
Day 3. Sneak into the office. Check if nobody's looking. Lock the door, disable the cameras. Install Cygwin on all machines, laughing maniacally.
Day 4. Come to work whistling cheerfully and do all the overdue work in 2 hours. Spend the rest of the time playing Nethack.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Why do zombies need brains?
Sent from my ASR33 using ASCII
WSH, not WMI... that's what I get for writing this at 1:30 in the morning. --TheReaperD
To be fair, Powershell isn't pre-installed, either. ;)
It is on Windows Server 2008 R2 and Windows 7
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*
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.
Adding another one to the list which is free, has command completion and debugging: PowerGui Editor for Quest http://www.powergui.org/
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
Why not keep to Perl, ok you need to compile it and the script will be as big as 500k, not as clean as a native supported scripting language, but still very effective.
Love many, trust a few, do harm to none.
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*
See: http://www.opsi.org/ (opsi is an open source Client Management System for Windows clients and is based on Linux servers.)
If there's any language you should learn for automation on windows, it's Python. I've worked as a build engineer in several companies and python has always been my rock in the windows environment. My background was awk and bash scripting but once I got a taste of Python, I never looked back.
This will return the package name you searched for, tab separated by it's install state. i.e. deinstall, install, hold, etc.
It'll only return what you described, if the package has been installed at some point in time and haven't been purged.
If the package in question haven't been install before or have been purged, you'll get "No packages found matching $PACKAGE" on stderr.
What automation tool is best for you depends, of course, a lot on what you need to do.
I've used Winbatch for years now. For basic stuff it is straightforward and easy to learn. But it still has the capabilities of performing sophisticated and complicated automated work.
With the right licence you can deploy compiled scripts to as many computers you like. I have dozens of scripts I use in this manner every day.
we make production lines and production line modules of all sort and we have pretty much everything run on windows, i have mostly patched up all my testing systems based on NI softwares, teststand + nidaq + NI488.2 + some .net code and you can get your system up and running in no time and trouble. getting tens of devices working together, controlling IO-s and measurement equipment over serial, GPIB, ethernet, USB or whatever is easy with these tools. NI Teststand is specialy crafted for testing systems and its great at it. in telecom devices testing its pretty much industry standard. some early attempts i made based on labview, very easy to make but result is not very good and maintainability is horrorshow
and start preparing for interviews. That is the only option that will let you keep your sanity.
If you'd have bothered to read what you are replying to, you'd have seen that the poster specifically mentions having to work against Sharepoint and Exchange.
I am just now using Python for an automation project.
It's a great glue to hold things together. With built in modules and pyserial, you've got IO covered. With pygame, you've got joystick and graphics support. Numpy handles your matrix inversions and vector calculus. Glade and Pygtk lets you create nifty GUIs. And Matplotlib handles the outputs.
Great plus: if you still decide to migrate to *nix, you won't have to rewrite a thing.
Best, Jonathan
Let me know when it's as ubiquitous as bash or csh.
bash is not preinstalled on many *nix systems. /bin/sh is ubiquitous and please, do not assume that it is bash. Fortunately, some Linux distributions undo that mistake. As for csh, it is widely regarded as being inadequate for scripting.
Powershell is about is ubiquitous as bash: It is present on most of the more widespread systems.
but improved upon it with object-oriented pipes
Made more complicated does mean improved.
I've been happy with a combination of CMD plus Jscript/COM/WMI integration but avoid VBscript due to the lack of robust error checking whereas Jscript has try/catch(ex) and is a more robust and familiar language. There aren't as many examples in Jscript but you can always convert from VBscript.
Powershell is a little like Perl and is the new standard where it can be found.
Search technet and msdn for things from The Scripting Guy and that should lead you to most of the useful references.
I also found MSI, via WiX, a useful way to distribute changes and you can build an MSI installer that doesn't actually install, I.e. It doesn't register software but it can run Jscript and deliver binary files.
Using Jscript in HTA is a great way to make web-gui-based admin tools.
WTF is wrong with the Slashdot UI? Comment threads are impossible to follow. Click to expand a comment and the screen jumps around to anywhere but the thread you are trying to follow. It's been doing this for what seems like a few weeks now and it has become tiresome in the extreme.
Why? Because you all keep saying it? It doesn't really work that way. Furthermore, ps, no matter its merits is only one tool. There are many others you will need to imitate to match Linux.
The soylentnews experiment has been a dismal failure.
When the .NET framework has incorporated all of what has built over the last 15 years in system management on MS systems (msi, [really, msi!] all the ntinternals tools, everything that visual test can do, tcpdumpsomething, remote control of different OS's, using more internet protocols) out of the box then it will be hard for it to jump out of the "I use it because this software needs it" to "I use it to launch all other tasks".
Windows wasn't designed for automation/server tasks. I predict lots of pain in your future.
- I've got bad karma because I won't parrot everyone else's opinion
#Load VMWare snap-in for powershell
LoadSnapin -PSSnapinName "VMware.VimAutomation.Core"
That showcases everything I hate about powershell right there.
/etc/bash_completion.d/vmware"
If it were linux, the command would be somethign like ".
What the hell is with PowerShell and switches to commands? It's like someone said "How can we possibly give users RSI by using our new interface? I've got it!! Type 700% more than they do in Linux!"
There's no place like
I wish Microsoft employees would stop posting questions on how to do their job on /.
The point was the grandstanding, the comment "I do have to say Powershell is pretty sweet" implied something interesting or insightful was going on. 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. 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. It's not exciting at all unless you haven't used any proper tools before.
Or, to put it simply, "there is nothing to see here". What you think of as the Rapture is a meh moment at best.
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*
If you know Perl, use it. There are lots of Win32 modules to help manage Windows. Additionally, you can compile using perl2exe and run your script on boxes that don't have Perl installed. Otherwise, learn Powershell.The specialized functions for managing Windows can't be beat for quick script creation.
#Load VMWare snap-in for powershell
LoadSnapin -PSSnapinName "VMware.VimAutomation.Core"
That showcases everything I hate about powershell right there.
That is a lot of hate for something you obviously do not know a lot about.
GP was mistaken. The command is actually Add-PSSnapin and the specific command could be written as
Add-PSSnapin VMware.VimAutomation.Core
Note how no parameter names or quotes were necessary (but still allowed).
If it were linux, the command would be somethign like ". /etc/bash_completion.d/vmware"
No, that would merely set up completion. A PowerShell snapin is actually a module which can have private namespaces to avoid collision in a global namespace, it can define new drives and providers etc. It is much more than completion. In fact, completion has nothing to do with it, completion will work even for script files which define parameters without any completion registration.
What the hell is with PowerShell and switches to commands? It's like someone said "How can we possibly give users RSI by using our new interface? I've got it!! Type 700% more than they do in Linux!"
PowerShell is just being extremely consistent, something Unix could learn a lot from! And PowerShell usually takes fewer keystrokes.
Don't be fooled when someone shows you a command and spells out all of the parameter names in full. That is usually just because they tab-completed them. PowerShell supports both consistent shortening of parameter names, parameter aliases as well as positional parameters. All of these in a very consistent and predictable way. This even goes for your own scripts and functions. PowerShell automatically infers parameter names from the command definition - i.e. there is no need to register external completion. You need to do the latter in traditional shells because the commands lacks parameter metadata.
Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
You can call the powershell modules from any .NET-language, as long as the windows automation libraries are installed - and Exchange needs those anyway.
So no, you don't _need_ to use powershell. But you might as well.
Maybe this fits your needs: http://channel9.msdn.com/Blogs/kmcgrath/Introduction-to-Creating-Coded-UI-Tests-with-Visual-Studio-2010
Utilities
Pay attention to the suggestions above from folks that already recommended good utility suites such as SysInternals, NirSoft, AutoIt!, etc. since they pretty much covered most of them.
Look into GnuWin32 for native Linux utilities such as sed, awk, grep, coreutils, textutils, and all the other utilities that you'd find on a Linux system for your windows servers. The only disadvantage is that you have to include two of the large multi-language libs that all exe from GnuWin32 depend on. (Use Depends to find out which ones.)
PowerShell .NET Framework (New-Object -TypeName System.Namespace... or directly with [System.Namespace...]), COM+ Automation Objects with (New-Object -ComObject ProdID), or execute utilities directly using their names or command prompt commands using cmd.exe /c.
I would recommended this now as a better language with more modern features over Command Prompt (Batch) and you can leverage it to execute all the other utilities and commands within and capture then process their stdin/err output simply. As the parent poster already mentioned that from within PS you can access a lot of the API's directly for automating windows such as Windows Management Interface (WMI) to query a lot of info but do very little,
Within PowerShell you have Invoke-Command and Enter-PSSession to simulate command line access similar to SSH as long as the remote server has WinRM (Windows Remote Management) interface installed and configured. You also have Job control and create by using commands with the -AsJob parameter or Start-Job commands. Some of the syntax in PS is borrowed from Bash and the pipeline ideaology of using output from one command and passing it to another as input is highly leveraged in PS and improved upon since it is object oriented allowing you to manipulate and filter out individual properties within those objects when they get passed down the pipeline giving you easier manipulation power over text and objects than you had with piping to sed, awk, or grep in your own scripts. (I still do quite a log of Batch scripting and piping to sed, grep, awk that I have on my system from the GnuWin32 utilities that I've installed that I find better and simpler to use directly than Cygwin.)
Many of the newer Microsoft and major applications include direct PowerShell modules to allow control of them and I've successfully used these modules for VMware, Citrix, SQL, Exchange, Sharepoint.
COM+ Automation
Other times I've directly accessed COM+ Automation object interfaces that are available from other software exe and dll libraries by discovering their ProgIDs with OLEView COM Automation listing or by directly interrogating the exe and dll files using Visual Studio Object Browser. Once you find the ProgID then you can look at the methods, properties, events, and other members that are exposed from within those objects and determine if you can instantiate or access instances of those objects to connect to these applications and control them using those object members. I've been able to discover a few applications that have these interfaces that are not very well publicised or documented by the vendors and use those to programmatically automate some third-party applications. PowerShell makes that easy as long as you don't have to retrieve or pass complex binary structures, otherwise you'd have to go to full C, C++, or C#.
64-to-32-bit
One thing about PowerShell is that you now have to be aware of 64-to-32-bit issues with Windows and the Windows/SysWow64 (32-bit windows apps and libraries on a 64-bit system) and Wow6432Node (32-bit Registry mapped on a 64-bit system).
There is also a bit of a caveat to be aware of when interfacing with COM+ objects across the 64-to-32-bit barrier on the same system since the 32-bit COM+ objects registered on a 64-bit system are only accessible from with a 32-bit instance of PowerShell x86 and remotely these 32-bit COM+ objects are only accessible in a 32
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*
LoL, I think you just proved my point. Historically, and present, virtually every other platform has had better mechanisms to deal with such things. Windows, with a lot of cobbled together technologies, still is not quite there. So, figured I'd simply help you avoid the troll mod by pointing out the lack of sarcasm that should have been in your post.
After all, "works most of the time" isnt "works all the time" and generally is not acceptable for such things. Thus, I thought your response was actually the perfect solution - "just dont do it" ;-)
StarTrekPhase2 - The Five Year Mission Continues!
Powershell is great, but not what I would call a great GUI test tool.
For that, use AutoIt.
I feel fantastic, and I'm still alive.
Believe me, coming from a Unix background you will go bat shit insane trying to figure out how to do the simplest of tasks on Windows. I have 8 years of Windows development experience and seriously contemplate leaving my job whenever I have maintain Windows code.
Um, "automatition?" (Bart has a breast fetish?)
I feel fantastic, and I'm still alive.
In my experience, python is a wonderful solution for these sorts of problems. With it's windows modules you can script using COM, manipulate the registry, access local and remote databases easily. Using the ssh protocol you can use standard deployment tools like fabric. Finally, you are using python so your scripts are likely to be easy to read and maintain. I create a standard local, private python installation for the purpose.
You have a problem with those error messages? If those exceptions look "worthless" to you then I would argue you don't really have any business automating anything remotely serious, and as such you probably have only the most basic programming experience. Powershell is completely self discoverable, meaning if you had taken about 5 minutes to read any introduction to the language you would have become acquainted with commandlets like Get-Help, Get-Command, and Get-Member. If the output of THOSE commandlets is "worthless" to you then you really are beyond hope. If you want to criticize Powershell be my guest, but try to do it for it's actual shortcomings instead of made up nonsense, like performance, or it's clunky remoting.
While writing software on Windows is always fairly hideous (especially for mass distribution, i.e. outside of a corporate environment) AutoIT is vastly underrated.
It's used quite a bit - for installer bootstraps (e.g. to do checks before running the MSI's) and on the AOL (UK) signup / support CD's.
By the standards of most UNIX utilities at ~ 500 KB (without compression) for small .exe's it may be a little on the large size (often the app it self I'm installing is only about 1.5 MB, and 500 KB of THAT is the MSI) but you can write something that will deploy on Windows XP (SP0+) through to Windows 7 and work very reliably with minimal development effort.
It's cute that it has a 'perlesque' syntax too (it's a sort of slightly horrible combination of Perl+PHP+VB, but which is immediately familiar to anyone with Unix shell scripting experience). The forums are pretty helpful places, and there are great examples of libraries from everything from simple SOAP clients to Blowfish implementations.
In practice, it more than makes up for the overhead, because effort can go into making better software, rather than spending days coming up with a simple but reliable utility that works on Windows XP SP0 through SP3 + Vista + Win 7, at various user levels (guest standard, admin, guest - with and without UAC) with no dependancies. Due to how much Windows XP has evolved, even if you support only SP2 and above there are large number of dependancies that are not always guaranteed to be there (different versions of Windows Installer, .NET, network support, small patches with fixes you may be relying on without knowing it, etc).
The only major deficiency I find in AutoIT is that while GUI support is enough to be useful, but there is no GUI development interface. Some might argue that's for the best - Real Studio probably better fit's the needs for any serious application development for anyone who isn't ready (or doesn't want to use) Visual Studio for a project. AutoIT is superb for administration, automation, small purpose built utilities and for quickly developing tools to compliment existing software though.
Thanks, that's interesting that there is a COM interface to Windows Update and it's that easy to query from PowerShell.
Check out the MSI API's. You can list versions there and handle upgrades/rollbacks just like you would with something like Solaris pkg's (not as automagic as apt-get + dpkg or yum + rpm, but scriptable and it's possible to do rollbacks and decent enough error handling).
Fair play to you, sir.
To understand recursion, you must first understand recursion.
What other things are needed to "match Linux"?
It's a native Win32 port of tcsh, with a bunch of the *nix tools you like. The downside is a) it's csh and b) you have to either pay $350 for a shell or pirate it.
tl;dr eat shit
The poster specifically mentioned exchange and sharepoint. Microsoft has created special PowerShell extensions just for those products. Not only can it leverage WMI, VBS and the rest of the windows alphabet soup, but powershell is a hell of a lot more secure out of the box (i.e. no Win server will execute powershell code unless the execution policy is set and the code is trusted within that scope).
PowerShell is a very, very concise language. Most of my VBs scripts could be compressed from fifty or 100 lines down to 3 lines or so. It's completely different syntax than anything else, but overall it's where the industry is headed.
I highly recommend you pick up a book or two on it, it's not hard to learn, but 9 times out of 10, you are trying to do the exact same thing someone else has already done very elegantly.
For enterprise stuff, make sure you are using code signing and ideally scoping your execution policy to accept only signed code from your company.
As far as scheduling, Windows Task Scheduler = Cron (ok, so maybe not 100% equal, but that's what us Win guys use to kick off scripts).
Also, you are probably in the wrong place to ask for Windows Enterprise advice, just an FYI.
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.
That is a lot of hate for something you obviously do not know a lot about.
GP was mistaken. The command is actually Add-PSSnapin and the specific command could be written as
Add-PSSnapin VMware.VimAutomation.Core
Note how no parameter names or quotes were necessary (but still allowed).
I have used it enough when dealing with Exchange to realize it has absurdly long commands and parameters regardless of how the original poster screwed up his example.
No, that would merely set up completion. A PowerShell snapin is actually a module which can have private namespaces to avoid collision in a global namespace, it can define new drives and providers etc. It is much more than completion. In fact, completion has nothing to do with it, completion will work even for script files which define parameters without any completion registration.
It seems like completion to me. You obviously know Linux too--so after I've done an {apt-get install | yum install | etc...} a program would be available for basic autocompletion like vmware in this example. You could type new[tab] and find new-vm. If the application installed autocompletion files, you could autocomplete parameters too without having to type in special load statements in bash.
In Windows it appears (at least from that example) that you have to install the program, then tell it to specifically load vmware related commands, objects, or whatever. I'm not saying it's a huge sticking point, but it appears to take much more work to define your automation in Windows verses Linux.
PowerShell is just being extremely consistent, something Unix could learn a lot from! And PowerShell usually takes fewer keystrokes.
As an example: I can only think of one utility in Linux that doesn't use '-r' for recursive actions on files. 'ls' uses '-R' for recursion and '-r' for reverse sort.
Don't be fooled when someone shows you a command and spells out all of the parameter names in full. That is usually just because they tab-completed them. PowerShell supports both consistent shortening of parameter names, parameter aliases as well as positional parameters.
I suppose you can type '--recursion' or '--recurse' in Linux.
All of these in a very consistent and predictable way. This even goes for your own scripts and functions. PowerShell automatically infers parameter names from the command definition - i.e. there is no need to register external completion. You need to do the latter in traditional shells because the commands lacks parameter metadata.
That's hardly a selling point for automation.
I'd still rather type 'postconf message_size_limit=1000000 mailbox_size_limit=100000000' than something like:
Get-AdSiteLink | Set-AdSiteLink -MaxMessageSize 40MB
Set-TransportConfig -MaxReceiveSize 40MB -MaxSendSize 40MB
Get-RoutingGroupConnector | Set-RoutingGroupConnector -MaxMessageSize 40MB
Get-ReceiveConnector | Set-ReceiveConnector -MaxMessageSize 40MB
Get-SendConnector | Set-SendConnector -MaxMessageSize 40MB
Get-Mailbox | set-mailbox -MaxSendSize 40MB -MaxReceiveSize 40MB
Either one can be stuck into a script and double-clicked on a new machine I suppose. I've never played around with Microsoft's SMS tools because they are ridiculously expensive--but with Puppet, Chef, CFEngine, etc... I can easily write 15 lines in Puppet that allow me to manage any postfix options. Another 10 lines and I can setup classes of machines for specific postfix configurations like spam filtering for crappy Exchange 2003 servers, full-on mail servers, mail relays, etc...
To automate our Postfix spam filter deployments, I setup a reference machine and tested it. Then I configured puppet and used a virtual machine to test my configuration making a few tweaks here and there. Finally I deployed a second live machine using my puppet con
There's no place like
By the same token, "works the same way as what Ken Thompson decided in 1970" does not mean better. In the case of Powershell's object pipes, I give a number of benefits.
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.
Doesn't python work on windows? I don't know about integrating with sharepoint or outlook though them programs is bad.
You missed the point yet again. I'm beginning to think you're being intentionally thick. While you've hem-hawed around the points I originally made, you can't do basic things such as produce a list of updates available to a system. This PowerShell relies on a hefty library of framework objects for pretty basic stuff. It's meh at best, and the more I hear about how exciting you think it is, the more I think you're simply a Microsoft fanboy trying to promote another half-assed tool.
But please do wake me when you feel you might have something interesting or insightful to add to the conversation. So far it's smoke and mirrors and I'll have no more of it.
You haven't been paying attention to the United States Congress lately. Besides shoving an official religion down the throats of Americans, they've also begun to torpedo woman's rights. There are now several things that women are not legally allowed to do without "a male family member". If you do not have a male family member available to sign off on what the female thinks she wants, the court will appoint a male representative.
I'm not saying I agree with either. I can't provide the specifics off the top of my head, but my girlfriend has been watching the issues carefully, and sending complaints to all congressional representatives involved. It's not because she's any kind of crazy fringe womans rights activist. It's because our government is coming out with some really fucked up laws.
The current Congress is trying to rapidly turn womens right backwards over 100 years. I wouldn't be terribly surprised if in the next 20 years it was turned back so far that women aren't allowed to drive, work outside of the home, or be allowed in public without a male relative present.
Serious? Seriousness is well above my pay grade.
Really? How's Amazon doing it?
Which API is that? Amazon's...
I'm a Puppet admin, I know what can be achieved with some hard work, but it is no thanks to Linux vendors/maintainers.
My issue is that the abstraction that makes this happen has to be bolted onto a unix system and if users modify the underlying configuration files the results are hard to predict. I assume Amazon's cloud resources have the same problems if you go outside their API to change things.
On the return codes, I asked how do you know if something got installed or not, 0/1 does not tell you this.
0 also means there was nothing to update (success). At the very minimum I expect 0/1 for any CLI utility, but yum's output is not suitable for processing by other commands, so there should be a lot more return codes. We get crap for feedback, and this is a core OS utility, and a core function. This problem however seeps all throughout Linux.
I wish Linux was more like Solaris in a lot of ways. Return codes, relative stability of any interfaces, stuff like that should be in all man pages not just really really old ones :\ I'm not saying Solaris is perfect, hehe, just a lot more mature.
You have a good point with Exchange vs. your linux mail server, but this is going outside the OS discussion and Exchange does a whole lot more than a typical unix mail server. Exchange even has an API to do "quiesce yourself so I can do a backup" where about any given Linux solution has "just grab the flat files and we'll pretend this integrity thing isn't really an issue". That is pretty typical of any Linux program.. flat files are "good enough" without further consideration of locking (visudo, vipw, etc, barf yack gross)
I love working with unix man, and I dig the whole everything is a file thing, but it's time to move on. We can keep configuration settings in flat files (hopefully the same syntax this time?), and still improve a LOOOOOOOT. You can have stable interfaces, command line AND programmatic AAAAAAND still have flat file backends with a universal syntax. You can even have a system where applications are notified when your configuration changes and still have flat files.
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.
Um... UNIX, POSIX.. then all the non-standards since then. I didn't think I'd have to explain that..
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.
Ok, on all the systems where task foo is enabled, change the minute to random(60)
Puppet can do this, and their crontab handler is not a simple piece of code. I imagine you simply cannot do this or put way too much faith into search/replace.
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?
Flat files are great for all that stuff - versioning, backups, etc, but that isn't configuration management. You can't just diff two sudoers files and figure out the effective differences. Nor httpd.conf, nor sendmail.cf, etc x1000 diff config syntaxes. Logically it is IS easier to diff exported registry settings, or Java property files.
Heh, tell me if the bonding settings are identical for any two Linux network interfaces. Pssst! Check both modprobe.conf and ifcfg-*! Do they actually match the running configuration?
Write a script to detect wether your sudoers file is vulnerable to this: http://sudo.miscellaneousmirror.org/sudo/alerts/runas_group_pw.html
Or pick any other soduers vulnerability from the past year. HINT: everything on that example line can be expanded into god-only-knows-what, so you will have to reimplement a good chunk of the sudoers parser.
But hey, you can do "echo >>" so you're all set right?
Yes, and you can install Kerberos on Linux.
Yah, and I won't hold my breath while you find ten Linux apps that support Negotiate authentication, much less ISV apps.
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?
In the sense that across a datacenter with multiple slightly different Linux distros and different patch levels, and hundreds of different BARELY parseable configuration syntaxes, you NEED a tool like Puppet to get anything done somewhat reliably, and those guys do a LOT of work laying down a sensible interface to a pile of random crap. You cannot manage a Linux datacenter with just "echo >>" and grep. No, you can, but BADLY.
Probably couldn't get it from that one command, but I could check the status before or after the fact:
I meant yum update, and did that actually do anything. The easiest way is to check mtime on /var/log/yum.log afterwards, and "then should I reboot or not" is some fun with "lsof | grep path inode"
It works but checking mtime on a log file to tell if an action was performed or not is STUUUUPID.
This is a "unix" system right? Why is the output unparseable? Why no detailed return codes?
0/1 is the bare minimum anything should have, that does not give any application specific information.
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?
http://www.microsoft.com/systemcenter/en/us/overview.aspx
That's addon software akin to Puppet but apparently way more advanced. So discounting addons, Linux wins on software distribution and loses on programatic configuration. Um... I'll just let you decide which one has more value and leave it at that. *goes back to tooling with custom Puppet module to manage something done easier on Windows...
Because all men can afford to support a woman, in the USA, right? We're not worried about women's rights here. You guys need us to get the real work done and to bring home the bacon.
Male==Fail.
That's why women are free in the first place. Men don't want us to be, but you're all such a bunch of total fuckups you really have no choice.
Of your sixteen uses of the word 'your' (possesive), it was only used six times correctly. The other ten times, you meant 'you're' (contraction of 'you are'). The content of your post seemed intelligent, but your delivery makes it seem as if you're uneducated, or uncaring/lazy in your writing.
I am not terribly familiar with remote package management, but would rpm be more explicit or useful for what you're doing?
What MSFT lover modded this troll? This man speaks truth in volumes.....
Powershell SUCKS SUCKS SUCKS SUCKS... only a braindead turd burgle would disagree with that.
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.
Just like you shouldn't expect bash scripts to run on a machine that hasn't had bash installed? Server 2008 and Windows 7 have it installed by default, FYI.
Karma: Poor (Mostly affected by lame karma-joke sigs)
PowerShell 2.0 is included in Server 2003 SP2, Vista SP1 and XP SP3. So assuming your machines are properly patched, you've got it.
Karma: Poor (Mostly affected by lame karma-joke sigs)
2.0 is included in XP SP3.
Karma: Poor (Mostly affected by lame karma-joke sigs)
JScript is also available by default. I think it beats VBScript by a long shot (and I've programmed a lot more VB than JavaScript), and has access to all the same Windows (and MS Office) objects. The MSE7 editor/debugger is available if MS Office is installed, and isn't too terrible for throwing some JScript or VBScript together. What's more, you can mix or match JScript, VBScript, and others (Rexx, Perl, etc.) that are not installed by default.
Um... UNIX, POSIX.. then all the non-standards since then. I didn't think I'd have to explain that..
You still haven't. Again, what is actually wrong with these interfaces? And if you're going to include that much history, can't I also cite the mess that is Win32?
Ok, on all the systems where task foo is enabled, change the minute to random(60)
Why would I ever want to do that?
Puppet can do this, and their crontab handler is not a simple piece of code. I imagine you simply cannot do this or put way too much faith into search/replace.
Also not really seeing the problem with that. In fact, crontab is already in a format which can be trivially read with grep, so I see little reason it couldn't be fixed with sed.
I'm also not sure why this is really an issue when you mentioned that Puppet already solves your problem.
You can't just diff two sudoers files and figure out the effective differences.
Unless they're dramatically different, it kind of does. And what are you comparing this to?
Logically it is IS easier to diff exported registry settings,
Really? Sudo vs exported registry settings? Unless you're going to get very specific about which registry settings we're talking about, I don't see the advantage -- the registry is otherwise about as useful for diffing as the entire filesystem.
Also, while I'm not sure how common it is, I am starting to notice tools with the ability to dump their configuration -- for instance,
Regardless, what I can do here is stuff an entire /etc into version control, then push out a given branch of that to give me a preconfigured machine. I'm sure tools exist to do something similar in the Windows world, but you're not going to get there by dumping arbitrarily fine chunks of the registry.
Heh, tell me if the bonding settings are identical for any two Linux network interfaces. Pssst! Check both modprobe.conf and ifcfg-*!
I can go one step further:
Now I know where to look for any differences between those interfaces -- which services are running on each of them, probably which ports are open on each of them, and so on.
Write a script to detect wether your sudoers file is vulnerable to this:
Wouldn't it be easier to update sudo? Also, the impact looks pretty fairly minor -- I don't have to enter my own password when logged in as myself to switch to... myself... but a group I'm not a member of.
you will have to reimplement a good chunk of the sudoers parser.
Possibly -- though this has largely been done, takes about 5 minutes on Google to find various sudoers parsers. That does suck, though -- postfix, for example, has a command which dumps all config values in an easily-parseable format.
you NEED a tool like Puppet to get anything done somewhat reliably,
Your example so far of something for which you need a tool like Puppet is... well... setting a cron job to fire at some random minute instead of at the same minute.
And what is wrong with needing Puppet, if that's the case? That fits perfectly well with the Unix philosophy -- why would you build that functionality into the system, if you can have a third-party tool that works just as well?
I meant yum update, and did that actually do anything.
I got that. Why doesn't my suggestion work?
The easiest way is to check mtime on /var/log/yum.log afterwards,
Doesn't mean it's the right way. That'll tell me whether it "did anything", but not whether it did what I want.
"then should I reboot or not"
Ubuntu Serv
Don't thank God, thank a doctor!
PS surpasses bash in terms of language features? Sure, bash is more a collection of commands than a language. If you need object orientation, remoting for automation purposes you get ruby or newlisp, iolanguage or a dozen other languages. But Windows and OSX automation do not surpass a FOSS unix environment because total control in the hand of the sysadmin is against the interest of the OS and applications owners. Possibly, powershell exists because and until bash does.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
I'm not sure what's scarier.
The fact that this guy is on essentially a *nix site with knowledgeable *nix users to ask for help but he's asking for Windows help....
or
the fact that a lot of the people posting answers to his question are obviously M$ knowledgeable and posting answers to his questions on a *nix site....
. .. ... /. has been invaded by the M$ Borg
I'm good with numbers -
If it's not in the .net framework, you can easily utilize c/c++ libs, also inserting jsp/html/vb is just as easy. And if you need more raw manipulation the Win32 libs via c/c++ work just as well.
I've created many automated applications in C# and have yet to find anything I cannot do...