Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Moving From *nix To Windows Automation?

timothy posted more than 3 years ago | from the setting-expectation-levels dept.

Programming 427

Zubinix writes "I have a background in doing automation in a Unix/Linux environment using scripting languages such as perl and bash shell, as well as ssh for remote scripting. My next project will be in the Windows environment so what approach and methodology is best for developing, say, the automation required for a test system? I don't want to use things like Cygwin, as I need to integrate with Windows applications such as Exchange and Sharepoint. Is there a list of should and should not dos when it comes to Windows automation?"

cancel ×

427 comments

Sorry! There are no comments related to the filter you selected.

Don't do it... (-1, Offtopic)

TheReaperD (937405) | more than 3 years ago | (#36052788)

Just don't. [/sarcasm]

Re:Don't do it... (3, Informative)

x*yy*x (2058140) | more than 3 years ago | (#36052824)

And why not? Powershell [microsoft.com] is perfect for the job.

Re:Don't do it... (1)

Anonymous Coward | more than 3 years ago | (#36052852)

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.

Re:Don't do it... (4, Interesting)

lucm (889690) | more than 3 years ago | (#36053210)

I don't agree. Powershell is actually very powerful as it can extend or be extended by the .Net framework. It is also very flexible, which is very convenient for systems automation.

Big enterprise schedulers, such as Tidal, have built-in support for Powershell and many enterprise storage solutions, such as Compellent, also have built-in support. Also VMWare has the very impressive PowerCLI, which is basically a series of extensions for Powershell that can automate almost everything in VirtualCenter.

Re:Don't do it... (5, Funny)

JWSmythe (446288) | more than 3 years ago | (#36052926)

      Day 1) Walk in the door, optimistic about what can be done with this "Enterprise" platform.

    Day 2) Walk in the door, with a headache, hoping to find an answer for how to manage what were simple tasks under *nix.

    Day 3) Walk in the door. Sit down at your desk. Plant your head firmly on the keyboard and cry.

    Day 4) Walk in the door, rip your soul out of your chest, stomp on it, and throw it in the nearest recycle bin. Sit down at your desk, and wonder why in 4 days you can't find a valid answer to automation that was so simple under *nix.

    Day 5) Walk in the door. Sit down at your desk, and think about how miserable you are now that you're working on a Windows-only network. Leave 2 hours early, and drink away your pain at the nearest bar.

    The longer it goes on, the worse the pain gets, until you realize that you have a stash of cheap liquor and pot in your desk drawer, and you use more of both in one day than an entire fraternity use in a hard partying weekend.

      I do have some answers for parts of it. Powershell is part of the answer, but far from complete, unless you like virtually every command you type returning worthless 6 line responses. Cygwin may solve some of the problems, but not all of them. ActivePerl may solve some problems. In the end, you will realize that everything is a mouse click away, and those mouse clicks are the only way to do it. Prepare to spend the rest of your life in remote desktop connections, and putting more miles on your mouse than you ever did playing first person shooters.

Re:Don't do it... (2)

snowgirl (978879) | more than 3 years ago | (#36052968)

      Day 1) Walk in the door, optimistic about what can be done with this "Enterprise" platform.

    Day 2) Walk in the door, with a headache, hoping to find an answer for how to manage what were simple tasks under *nix.

    Day 3) Walk in the door. Sit down at your desk. Plant your head firmly on the keyboard and cry.

    Day 4) Walk in the door, rip your soul out of your chest, stomp on it, and throw it in the nearest recycle bin. Sit down at your desk, and wonder why in 4 days you can't find a valid answer to automation that was so simple under *nix.

    Day 5) Walk in the door. Sit down at your desk, and think about how miserable you are now that you're working on a Windows-only network. Leave 2 hours early, and drink away your pain at the nearest bar.

    The longer it goes on, the worse the pain gets, until you realize that you have a stash of cheap liquor and pot in your desk drawer, and you use more of both in one day than an entire fraternity use in a hard partying weekend.

All of this is true. The answer Microsoft themselves came up with? Perl for Windows. There was also a horrible mess of garbage in CMD script that was the *nix equivalent to #!/usr/bin/perl ... so that we could run perl scripts from the command line without typing "perl scriptname.pl" first... it was about a good 25 lines of code...

Re:Don't do it... (1)

spacecowboy420 (450426) | more than 3 years ago | (#36053102)

Yeah, on linux it was:
Day 1) Find autoexpect, leverage that with some bash/perl/python/tcl etc foo
Day 2) Done

Re:Don't do it... (1)

ace999 (2105666) | more than 3 years ago | (#36053040)

And remember why you initially did your automation on *nix based platforms...

Re:Don't do it... (1)

RobertM1968 (951074) | more than 3 years ago | (#36053106)

Just don't. [/notsarcasm]

FTFY! ;-)

A millions monkeys comes to mind (-1, Offtopic)

Foofoobar (318279) | more than 3 years ago | (#36052792)

that and banging your head on your keyboard until the world makes sense again.

Re:A millions monkeys comes to mind (0)

Anonymous Coward | more than 3 years ago | (#36052892)

Mod parent up.

Dos and Donts (0)

Anonymous Coward | more than 3 years ago | (#36052796)

Dont:
Windows Automation

Powershell (0)

Anonymous Coward | more than 3 years ago | (#36052798)

'nuff said

WMI (5, Informative)

stanlyb (1839382) | more than 3 years ago | (#36052810)

Your answer to everything is WMI. Just start command prompt, type :> wmic And voila, you are ready

Windows Powershell (0)

Anonymous Coward | more than 3 years ago | (#36052820)

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.

Windows Powershell (0)

Anonymous Coward | more than 3 years ago | (#36052822)

not too many options - Windows PowerShell, that's about it.

Re:Windows Powershell (1)

19thNervousBreakdown (768619) | more than 3 years ago | (#36053266)

The fact that you need to integrate with Exchange pretty much makes this a necessity. Even if you go with something else, you'll have to do PowerShell to talk to Exchange.

Is not the question backwards? (1)

lsolano (398432) | more than 3 years ago | (#36052828)

Is it?

a VM... (1, Funny)

Anonymous Coward | more than 3 years ago | (#36052832)

> 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.

Re:a VM... (0)

telekon (185072) | more than 3 years ago | (#36052900)

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.

^ Best suggestion whole thread.

Re:a VM... (2)

ModernGeek (601932) | more than 3 years ago | (#36053208)

The only way that Microsoft can improve Windows at this point is to make it run well on virtual machines so that it can be a little bit easier to migrate away from.

Re:a VM... (4, Interesting)

JWSmythe (446288) | more than 3 years ago | (#36052990)

    Amazingly enough, that's something I'm doing right now. (no, I'm not the original author). I smoothed over the rough spots as much as possible, and now we're doing the Linux migration. It's a long, slow process to change a decade of deep rooted Windows-isms, but it will happen soon enough. The only Windows that will be left will be the workstations for those who choose not to switch over to Linux. In a web based enterprise, there's no excuse for being locked into any platform.

Re:a VM... (3, Funny)

Anonymous Coward | more than 3 years ago | (#36053156)

Why would you switch to Linux - an inferior, security ridden, and an OS which can't stay up longer than a month?!
It's a hobbyist OS at best and doesn't survive in a real commercial environment.

Learn VBScript (2)

MrEricSir (398214) | more than 3 years ago | (#36052838)

Hate to say it, but you should probably learn VBScript. There's a VBScript interpreter is built into Windows, and it can interact with COM. It might be a pain, but it will suit your needs.

Re:Learn VBScript (0)

Anonymous Coward | more than 3 years ago | (#36053244)

Well, when you're leaving bash, VBScript is actually an improvement. For all its limitations, at least it's half-a-decent programming language. And if half-a-decent isn't good enough, you might opt to actually move on to VB or C++ or Python or whatever strikes your fancy. All Windows automation that you might want to do is exposed through a COM interface and there is no programming language targeting the Windows platform that doesn't include support for COM.
On a personal note, when decided to switch from command scripts to a programming language, I was afraid that it would be hard. But it turned out that most things are actually easier (if at times a bit more tedious) and it's a lot harder to shoot yourself in the foot in most of them. At the very least you'll never get errors caused by the unpredictable script syntax again.

PowerShell (0)

Anonymous Coward | more than 3 years ago | (#36052848)

Windows automation now-a-days == PowerShell. It is actually powerfull and pretty well thought through.

Or... (2)

dzr0001 (1053034) | more than 3 years ago | (#36052860)

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.

Tons of options (3, Interesting)

Skuld-Chan (302449) | more than 3 years ago | (#36052866)

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.

All I can think about is... (-1)

Anonymous Coward | more than 3 years ago | (#36052870)

Migrate the Windows machines to *nix...

Oh...wait...NM :)

I'm out - that's the only option I could come up with.

Assuming you absolutely have to use Windows... (5, Interesting)

Alanbly (1433229) | more than 3 years ago | (#36052872)

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.

Re:Assuming you absolutely have to use Windows... (2)

Meshach (578918) | more than 3 years ago | (#36053216)

In a similar vein TestComplete from AutomatedQA is another tool that provides a similar experience. There are several different available languages (VB, Delphi, ...) and they provide a wide range of methods from a simple Record/Play to coding.

Also VMware is another tool good for setting up multiple "clean" systems for testing.

Re:Assuming you absolutely have to use Windows... (2)

religious freak (1005821) | more than 3 years ago | (#36053230)

I'll second this. QTP is *the* standard for automated testing. There are others, but QTP is the best. If you want more info check out this forum.

sqaforums.com - look up Quick Test Pro and get to work. Everyone talking unix is talking nonsense. If you're in a Windows environment, you work with that. You go in talking unix stuff and you're likely to get fired.

Re:Assuming you absolutely have to use Windows... (1)

religious freak (1005821) | more than 3 years ago | (#36053242)

Ah - I will say that if budget is an issue some of the other options like vbscript will work, but they're more labor intensive. Do yourself a favor and push for QTP.

autoit (0)

Anonymous Coward | more than 3 years ago | (#36052878)

autoit or powershell are about as good as it gets for windows automation.

Re:autoit (1)

Jonah Hex (651948) | more than 3 years ago | (#36052976)

AutoIT [autoitscript.com] gives you the flexibility to make Windows your bitch.

HEX

Re:autoit- THIS! (1)

j-stroy (640921) | more than 3 years ago | (#36053108)

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.

Windows Automation (-1, Offtopic)

telekon (185072) | more than 3 years ago | (#36052880)

What I read:

I have a background doing things in a logical way, in a stable environment that actually works, but thanks to some incompetent beancounters who have traded the company cow for some buzzword-compliant magic beans, my next project will be building an igloo in the ninth circle of hell.

But for the sake of supporting 'Ask Slashdot':

DO:

  • not use Windows

DO NOT:

  • use Windows.

C++ (1)

Grindalf (1089511) | more than 3 years ago | (#36052890)

C++ is much faster than all that stuff, I've used it for years - it's a synch! Top Tip!

Powershell (0)

Anonymous Coward | more than 3 years ago | (#36052896)

Powershell is probably your best bet.

Embrace the Dark Side (.net) (5, Informative)

spacecowboy420 (450426) | more than 3 years ago | (#36052898)

So, been down this EXACT road. I was doing Linux automation, was so effective was brought in to do Windows too - yea!
Anyway, tried the cygwin route... It went OK, but just not quite it.
Went the vbscript route for a while (pure hell), but could work with wmi and had the windows objects available.

Soon, I started writing console apps in C# to make the trickier stuff happen. The .Net framework made it all so easy.

My final set of tools came to be powershell (access to the .net framework, you can do almost anything), Systernals psexec (for running processes on remote machines), and basic vbscript .bat. I had it set up with a web interface so I could enter a dos command into a web interface and point it a machine. It would build the bat and run it on the remote machine and return the standard out. This allowed me to add IIS sites and app pools, install com components, install apps, run msunit tests, and basically do whatever I wanted to any machine on the domain. Took me a quarter to build, but worked well. I've moved on in the company, but my replacement is still using it.

Re:Embrace the Dark Side (.net) (1)

Mia'cova (691309) | more than 3 years ago | (#36052946)

PowerShell supports remoting now which is nice.

Re:Embrace the Dark Side (.net) (2)

spacecowboy420 (450426) | more than 3 years ago | (#36053068)

I used remoting for some stuff, but for some reason, psexec just worked easier. Plus it was easier to specify a user on the command line. I know, I could have done it with config files but when I wanted to do just a one off dos command, it was just easier.

Re:Embrace the Dark Side (.net) (1)

Zubinix (572981) | more than 3 years ago | (#36052982)

Good response. Thanks!

Re:Embrace the Dark Side (.net) (2)

shutdown -p now (807394) | more than 3 years ago | (#36053148)

Note that you don't need C# to deal with .NET and related stuff. IronPython [codeplex.com] can use anything from .NET directly just as well, but also has many stock Python modules available. And it might be more familiar to someone with Unix background, and its dynamic nature is better suited for scripting tasks typical of automation.

There's also IronRuby [codeplex.com] if you prefer the language.

Re:Embrace the Dark Side (.net) (-1)

Anonymous Coward | more than 3 years ago | (#36053264)

... was brought in to do Windows too - yea!

Yea? What are you voting on?

Oh, I guess you meant yeah.

Dictionaries are quite useful.

...should not dos when it comes to Windows... (1)

Trogre (513942) | more than 3 years ago | (#36052904)

I see what you did there.

Waaa! (0)

Anonymous Coward | more than 3 years ago | (#36052912)

Do my job for me! Waaa!

Re:Waaa! (0)

Anonymous Coward | more than 3 years ago | (#36053142)

What an absolute dickbag, asking a community of experts for advise while researching a problem that is new to him. Were I this guy's boss, I'd fire him and hire a guy who could figure out solutions to novel problems by staring a blank wall. At least, then, I'd know that he wasn't slacking off on the job. Or something.

Get familiar with PowerShell (0)

Anonymous Coward | more than 3 years ago | (#36052914)

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!

PowerShell (1)

Mia'cova (691309) | more than 3 years ago | (#36052920)

By far your best option. It can take a while to learn though. SharePoint and Exchange use powershell as their main interface for scripting.

Re:PowerShell (0)

Anonymous Coward | more than 3 years ago | (#36052954)

Agreed. Powershell, vbs and windows scheduler.

Do NOT try to program your own event scheduler. It WILL fail. I read that somewhere else, ignored it, and can save you time by saying it's true.

From unix to windows.... (-1, Troll)

Lumpy (12016) | more than 3 years ago | (#36052924)

You have really only 2 options....

Learn and tolerate powershell...

buy a nice pistol, put it in your mouth and pull the trigger.....

Both have the same amount of pain and misery attached to them.

Re:From unix to windows.... (1)

Anonymous Coward | more than 3 years ago | (#36053206)

I have zero experience with powershell, but it seems like you're saying it's a quick, painless solution.

this is a question more for stackoverflow (4, Interesting)

gbrandt (113294) | more than 3 years ago | (#36052932)

http://stackoverflow.com/ [stackoverflow.com] has experts that go there just to help with questions like this.

Re:this is a question more for stackoverflow (4, Informative)

Krishnoid (984597) | more than 3 years ago | (#36053112)

You might also have good luck with http://serverfault.com/ [serverfault.com] or http://superuser.com/ [superuser.com] under the windows and automation tags. Having collected a toolset myself, I'd point you to sysinternals and nirsoft for diagnostic and informational utilities (check out wscc and nirlauncher for a one-stop place for these), autohotkey for automation scripting, and http://portableapps.com/ [portableapps.com] for apps and general utilities, as a starting point. You can run most or all of these without installing them locally and adding cruft to your registry and random stuff around your filesystem.

I'd also recommend having a Linux box; you can work in a familiar environment, then share out batch scripts you write via Samba -- read-only for binaries dirs that don't mind being unable to write out config files; writeable (but perhaps not listable) for a centralized location for saving off output from your various scripts, and so forth.

VBScript and/or PowerShell (2)

blincoln (592401) | more than 3 years ago | (#36052934)

VBScript is included with any version of Windows you're likely to be working with, is mature, and stable. That having been said, it has the boneheaded pre-.NET Visual Basic syntax, so you may hate yourself for choosing it.

PowerShell is either included with or available as an add-on for most versions of Windows you're likely to be working with. It has a much nicer syntax that is inspired by several Unix/Linux scripting languages, and can make use of .NET assemblies, which is *very* powerful. However, my experience with it was that it wasn't 100% ready for primetime. I've written hundreds of VBScripts, but before I'd hit ten PowerShell scripts, I ran across a nasty bug related to one of the wildcard syntaces (is that even a word?) that the language supports - if I tried to use a for loop to iterate through a list of directories, and any of the directory names included square brackets, I was basically out of luck. There had been a workaround in older versions of PS, but not in the one I was using. Maybe MS eventually fixed this, but if so it literally took years.

In an ideal world, I'd recommend PowerShell, because it can do a lot more, and typically with less script code. But I play it safe by sticking with VBScript, at least until the issues with PS are worked out.

Re:VBScript and/or PowerShell (2)

shutdown -p now (807394) | more than 3 years ago | (#36053164)

VBScript is included with any version of Windows you're likely to be working with, is mature, and stable. That having been said, it has the boneheaded pre-.NET Visual Basic syntax, so you may hate yourself for choosing it.

You don't need to use VBScript with Windows Scripting Host (which is what that thing is called). It also supports JScript out of the box, and if you value your sanity that's what you should use. It's not 100% conformant ECMA-262 implementation, but it's pretty close, and either way it's a much more powerful and readable language than VBScript.

The general problem with WSH is that it's COM-based. If software you automate exposes COM interfaces (e.g. Visual Studio), then it's all good. But newer stuff often only has .NET-only APIs for those things, and WSH won't help you there.

Re:VBScript and/or PowerShell (1)

toupsie (88295) | more than 3 years ago | (#36053300)

Try -literalPath instead of -path to overcome this.

OK SO DOES ANYONE REMEMBER VERA LYNN OR NOT ?? (-1)

Anonymous Coward | more than 3 years ago | (#36052940)

This has been haunting me for over 30 years !!

http://www.imdb.com/name/nm0528822/bio [imdb.com]

Dr. Strangelove (-1)

Anonymous Coward | more than 3 years ago | (#36052988)

She is the singer of "We'll Meet Again" at the end of the movie.

Powershell (0)

Anonymous Coward | more than 3 years ago | (#36052942)

That is all.

Heres how you do it! (-1, Redundant)

a_n_d_e_r_s (136412) | more than 3 years ago | (#36052948)

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.

IronPython (0)

Anonymous Coward | more than 3 years ago | (#36052998)

I would have said Python alone, which has some pretty good cross-platform support, but IronPython also has access to the entire .NET platform.

ColdFusion integrates well with MS products (2)

WebManWalking (1225366) | more than 3 years ago | (#36053052)

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.

Sadly, it's vbscript (1)

Anonymous Coward | more than 3 years ago | (#36053066)

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.

Best practices are best practices (2, Interesting)

onyxruby (118189) | more than 3 years ago | (#36053078)

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.

Re:Best practices are best practices (1)

Zubinix (572981) | more than 3 years ago | (#36053170)

What you really haven't done is explained your need very well

The role is rather adhoc. I could be scripting some testing processes that move files around and import into databases or I could be adding features to Outlook...for example a simple timesheet and leave application interface that would send leave requests to the appropriate manager. Being able to quickly prototype something is essential here.

Re:Best practices are best practices (1)

1000101 (584896) | more than 3 years ago | (#36053294)

SharePoint has basic workflow functionality out of the box. If you're looking for simple timesheet and leave application requests that route tasks to managers then don't kill yourself writing custom scripts. Those types of applications can be built in no time with standard SharePoint lists/calendars and approval workflows

Bad luck (0, Troll)

starfishsystems (834319) | more than 3 years ago | (#36053094)

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.

Re:Bad luck (1)

TrancePhreak (576593) | more than 3 years ago | (#36053202)

You can automate point & clicking on Windows.

Re:Bad luck (1, Insightful)

starfishsystems (834319) | more than 3 years ago | (#36053278)

Just not meaningfully.

Re:Bad luck (1)

F-3582 (996772) | more than 3 years ago | (#36053222)

Luckily a growing portion of applications for Windows bring their own Powershell cmdlets for low-level access, nowadays. I was told that Office 2010 is basically a (huge) bunch of Powershell cmdlets and the GUI just wraps around them.

Let me translate the /. replies so far... (2, Informative)

Anonymous Coward | more than 3 years ago | (#36053098)

"I am a one trick pony who cannot learn to do things in other operating systems because my ego gets in the way."

Go elsewhere to seek advice. I'd suggest stackoverflow.com

Use automation for automation (2, Informative)

Anonymous Coward | more than 3 years ago | (#36053126)

Use a decent automation engine, will save you years of headaches and maintenance. There are pros and cons though.

Ones such as BMC Bladelogic or HP Server Automation (opsware) are probably the best out there (enterprise-grade).

Be forewarned: they are not cheap. Best for enterprises 100+ systems. The more, the better ROI.

Re:Use automation for automation (1)

lucm (889690) | more than 3 years ago | (#36053238)

Opsware (now HP Operations Orchestrator) is just awesome. Besides lots and lots of plugins and templates it has a very cool feature which allows you to create a new workflow item based on a web service signature (WSDL).

Powershell (3, Insightful)

technoviper (595945) | more than 3 years ago | (#36053132)

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.

OLE Automatisation (2)

Casandro (751346) | more than 3 years ago | (#36053144)

One possible way is OLE automatisation, but be prepared of the horrors of it.

Re:OLE Automatisation (1)

shutdown -p now (807394) | more than 3 years ago | (#36053194)

OLE Automation [wikipedia.org] is a set of general-purpose scripting extensions on top of COM - defining various interfaces that permit dynamic dispatch, RTTI and other such things. It doesn't actually have anything to do with automation as such, except that it used to be the preferred way for applications to expose automation APIs should they have any - so whether there are any "horrors" involved or not, or whether there is any support at all, depends entirely on the application.

This is now superseded by PowerShell, in any case.

Python? (1)

Bazman (4849) | more than 3 years ago | (#36053158)

With the win32api module, can do Windowsy stuff, and you can transfer all your python skills from your Unix days. You do have Python skills don't you? Well, get some.

There's a native port of Python so no need for cygwin.

Don'ts (4, Informative)

stewbacca (1033764) | more than 3 years ago | (#36053166)

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.

I have to promote Microsoft products... (5, Funny)

Anonymous Coward | more than 3 years ago | (#36053180)

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 (1, Insightful)

Anonymous Coward | more than 3 years ago | (#36053182)

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.

Multiple tools (0)

Anonymous Coward | more than 3 years ago | (#36053188)

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:
find /i "thing I want to look for" *filenames*
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.

WRONG WAY (0)

Anonymous Coward | more than 3 years ago | (#36053192)

TURN BACK

(Sign you see in UK&Ireland when you get off the ferry on the wrong side - they drive on the left)

Powershell and other tools (5, Informative)

thalakan (14668) | more than 3 years ago | (#36053196)

Powershell. The only tool that knows how to talk to all the different frameworks in Windows is Powershell. No other tool can talk to .NET, COM, WMI, native APIs (via P/Invoke), and external stdio based tools. If you can't do the automation you want using something in one of the above frameworks, you've got bigger problems than finding a good automation tool.

Since the test guy usually has to be a part time sysadmin too, you should be aware of these tools:

System update readiness tool: http://support.microsoft.com/kb/947821/en-us [microsoft.com]
WMI diagnostic utility: http://www.microsoft.com/downloads/en/details.aspx?familyid=d7ba3cd6-18d1-4d05-b11e-4c64192ae97d&displaylang=en [microsoft.com]
gplogview: http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=BCFB1955-CA1D-4F00-9CFF-6F541BAD4563 [microsoft.com]
Windows SDK (including debugging tools for windows): http://www.microsoft.com/downloads/en/details.aspx?FamilyID=35AEDA01-421D-4BA5-B44B-543DC8C33A20 [microsoft.com]
ollydbg: http://www.ollydbg.de/ [ollydbg.de]
sysinternals suite: http://technet.microsoft.com/en-us/sysinternals/bb842062 [microsoft.com]
Windows Management Framework: http://support.microsoft.com/kb/968929 [microsoft.com]
WDK: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=36a2630f-5d56-43b5-b996-7633f2ec14ff [microsoft.com]
WAIK: http://www.microsoft.com/downloads/en/details.aspx?familyid=696DD665-9F76-4177-A811-39C26D3B3B34&displaylang=en [microsoft.com]
Windows 7 SP1 WAIK supplement: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=0AEE2B4B-494B-4ADC-B174-33BC62F02C5D [microsoft.com]

If XP is involved, check out Windows SteadyState. It's like deepfreeze, if you've ever used that. qemu is also a great way to boot test machines and capture output at scale; using CoW disks you can have fresh machines every time you boot regardless if the test machines are XP or not.

Re:Powershell and other tools (1)

Zubinix (572981) | more than 3 years ago | (#36053302)

Lots of useful info at those links. Thanks!

Python (1)

motek (179836) | more than 3 years ago | (#36053200)

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.

autoit? (0)

Anonymous Coward | more than 3 years ago | (#36053204)

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)

Opalis (0)

Anonymous Coward | more than 3 years ago | (#36053212)

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.

What versions? (1)

CannonballHead (842625) | more than 3 years ago | (#36053220)

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...)

Re:What versions? (1)

Zubinix (572981) | more than 3 years ago | (#36053314)

I would imagine Windows XP and later.

Opalis (1)

lucm (889690) | more than 3 years ago | (#36053226)

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.

So sorry (1)

SnarfQuest (469614) | more than 3 years ago | (#36053248)

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.

Maybe try this? (0)

Anonymous Coward | more than 3 years ago | (#36053250)

http://www.csscript.net/

List... (1, Troll)

frank_adrian314159 (469671) | more than 3 years ago | (#36053272)

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...

For COM, use COM tools (0)

Anonymous Coward | more than 3 years ago | (#36053280)

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 [microsoft.com]

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.

Go with Perl (0)

Anonymous Coward | more than 3 years ago | (#36053284)

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.

Go sharpen up a spoon (0)

steelwraith (141362) | more than 3 years ago | (#36053292)

so that you can give yourself a pre-frontal lobotomy to bring yourself down to Windows level...

AutoIt (1)

PhilHibbs (4537) | more than 3 years ago | (#36053304)

AutoIt is brilliant, I've had a lot of fun with it. Some people like AutoHotKey, but I can't get used to the syntax. I'm dabbling with MacroMonkey which looks like it can do a lot of the same stuff with a better language (Lua) but not as well-developed a library and nowhere near the same community as AutoIt (although there are some very abrasive personalities on the forum).

It is not about scripting alone (1)

octogen (540500) | more than 3 years ago | (#36053308)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>