Forgot your password?
typodupeerror
Programming Unix Windows Linux

Ask Slashdot: Moving From *nix To Windows Automation? 427

Posted by timothy
from the setting-expectation-levels dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Moving From *nix To Windows Automation?

Comments Filter:
  • WMI (Score:5, Informative)

    by stanlyb (1839382) on Friday May 06, 2011 @06:59PM (#36052810)
    Your answer to everything is WMI. Just start command prompt, type :> wmic And voila, you are ready
  • by MrEricSir (398214) on Friday May 06, 2011 @07:01PM (#36052838) Homepage

    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.

  • 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 (Score:4, Interesting)

    by Skuld-Chan (302449) on Friday May 06, 2011 @07:04PM (#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.

  • by Alanbly (1433229) <alanbly@gmail.com> on Friday May 06, 2011 @07:04PM (#36052872) Homepage
    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.
    • by Meshach (578918)
      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.
    • 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.
      • 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.
  • by spacecowboy420 (450426) * <[moc.liamg] [ta] [neetsacr]> on Friday May 06, 2011 @07:06PM (#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.

    • by Mia'cova (691309)

      PowerShell supports remoting now which is nice.

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

    • by KevMar (471257)

      There is a lot of power in PowerShell remoting now and its easier than ever to use now.

      Get-Content .\computers.txt | %{ Invoke-Command -ComputerName $_ -AsJob -ScriptBlock { gpupdate /force } }

      This works great for simple stuff. The commands in the -ScriptBlock are ran on the target computer. The -AsJob is not needed, but it basically multi threads the command. Running it on every computer at the same time instead of one at a time. You have to use get-job and related commands to check up on them, but its

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

      Took me a quarter to build, but worked well.

      I've moved on in the company, but my replacement is still using it.

      So... you built SSH for your current Windows setup, in 3 months. I'm glad *nix comes with that little gem so that each IT department using *nix doesn't have to roll their own (like you had to on Windows). Let's hope your program is well documented, and works easily after the next Windows revision...

      I'm glad you were able to hack together your own solution, but wouldn't it be great if MS gave you those options at the CLI and a remote command line interface out of the box, instead of requiring you to bui

  • I see what you did there.

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

  • by gbrandt (113294) on Friday May 06, 2011 @07:10PM (#36052932)

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

    • by Krishnoid (984597) * on Friday May 06, 2011 @07:32PM (#36053112) Journal
      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.

  • by blincoln (592401) on Friday May 06, 2011 @07:10PM (#36052934) Homepage Journal

    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.

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

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

      The general problem with WSH is that it's COM-based. If software you automate exposes COM interfaces (e.g. Visual Studio), then it's all good. But newer stuff often on

    • by toupsie (88295)
      Try -literalPath instead of -path to overcome this.
  • 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.
  • by onyxruby (118189) <{onyxruby} {at} {comcast.net}> on Friday May 06, 2011 @07:26PM (#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.

    • 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

  • by Anonymous Coward

    "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

  • by Anonymous Coward

    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.

    • by lucm (889690)

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

  • Powershell (Score:3, Insightful)

    by technoviper (595945) <technoviperx.yahoo@com> on Friday May 06, 2011 @07:34PM (#36053132) Homepage
    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.
  • by Casandro (751346) on Friday May 06, 2011 @07:35PM (#36053144)

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

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

      This is now superseded by PowerShell, in an

  • by Bazman (4849)

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

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

  • Don'ts (Score:5, Informative)

    by stewbacca (1033764) on Friday May 06, 2011 @07:38PM (#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.

  • by Anonymous Coward on Friday May 06, 2011 @07:39PM (#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.

  • by thalakan (14668) <jspence AT lightconsulting DOT com> on Friday May 06, 2011 @07:42PM (#36053196) Homepage

    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.

  • by motek (179836)

    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.

  • 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...)
  • by lucm (889690)

    Have a look at Opalis, which has been acquired by Microsoft and is now part of the System Center suite. It is a very interesting runbook automation environment with plugins for most Windows-related tasks. It is graphical and pretty user-friendly, and if something cannot be done natively you can extend it with Powershell.

  • AutoIt 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 la
    • This is a more complex problem than what scripting language you are going to use. Automating things is about job management, process management, signals, connecting streams and terminals, setting device modes, filesystem permissions, modifying network settings, and many other things.

      Agreed. And that is what PowerShell excels at - on the Windows platform.

      Unix is designed in a way that lets you change almost every property of the system in numerous ways, following general principles of its architecture. It is a very logical and consistent system.

      Yes, bit the fact that Unix same up with this good idea 30 years ago does not mean that it is *the only* such system or even that the *nix way of doing things cannot be improved upon.

      The problem is that Windows lacks such an modular, abstract foundation.

      Are you for real? Have you any idea about Windows foundation? Unlike Unix, Windows' foundation is almost exclusively object-oriented. Most/all core API are exposed through COM which is an object-oriented foundation which allow much finer-grained access than

  • by bertok (226922) on Friday May 06, 2011 @08:11PM (#36053424)

    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.
    - Enable unsigned scripts to run. Preventing .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 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.

  • by PPH (736903) on Friday May 06, 2011 @09:41PM (#36053860)

    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.

  • by Jane Q. Public (1010737) on Friday May 06, 2011 @10:26PM (#36054096)
    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.
  • by Tim99 (984437) on Saturday May 07, 2011 @12:55AM (#36054572)
    Most replies that steer you towards Microsoft tools will probably suggest Powershell.

    Old timers still tend to use cmd.exe. A Command line reference can be found here: http://technet.microsoft.com/en-us/library/cc772390(WS.10).aspx [microsoft.com] You can still usethe > and >> pipe; and DOS commands like copy and xcopy are quite similar to cp.

    An overview of Windows 2008 administration using the command promt can be found here: http://technet.microsoft.com/en-us/magazine/dd673654.aspx [microsoft.com] Set the appopriate permissions for your .cmd/.bat shell files - If UAC is on, you can right click on the file and select the compatibility tab. You can choose the option to “run this program as an administrator”. If you turn off UAC, the option should be grayed out - In which case you right click on the file and choose “Run as Administrator”. To automate running of cmd.exe files use the Task Scheduler MMC Snap-in User Interface - appropriate permissions are set with the credential manager.

Some people carve careers, others chisel them.

Working...