&lt;?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Articles from August 2012 on PowerShell.org - Welcome Automaters!</title><link>https://powershell.org/articles/2012/08/</link><description>Recent content in Articles from August 2012 on PowerShell.org - Welcome Automaters!</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://powershell.org/articles/2012/08/index.xml" rel="self" type="application/rss+xml"/><item><title>PowerShell Workflow: When Should You Use It?</title><link>https://powershell.org/articles/2012-08-30-powershell-workflow-when-should-you-use-it/</link><guid>https://powershell.org/articles/2012-08-30-powershell-workflow-when-should-you-use-it/</guid><pubDate>Thu, 30 Aug 2012 16:29:19 +0000</pubDate><description>&lt;p&gt;Microsoft recently posted the online help for PowerShell v3 Workflow (&lt;a href="http://technet.microsoft.com/en-us/library/jj134242)"&gt;http://technet.microsoft.com/en-us/library/jj134242)&lt;/a&gt;, and I wanted to take an opportunity to explore some of what the help says - and perhaps offer an outsider&amp;rsquo;s perspective.&lt;/p&gt;
&lt;h2 id="what-is-workflow" class="ps-heading"&gt;What is Workflow?&lt;a class="ps-heading-anchor" href="#what-is-workflow" aria-label="Link to this section" title="Link to this section"&gt;&lt;i class="fas fa-link" aria-hidden="true"&gt;&lt;/i&gt;&lt;/a&gt;
&lt;/h2&gt;
&lt;p&gt;Workflow is a set of technologies included with PowerShell v3, and is available on any computer running v3 (which can include Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows 8, and Windows Server 2012). A workflow is a special kind of PowerShell script that looks a lot like a function. When run, however, PowerShell translates the workflow to Windows Workflow Foundation (WWF) code, and hands it off to WWF to execute. That means the contents of a workflow are a bit different than the contents of a script.&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>Microsoft recently posted the online help for PowerShell v3 Workflow (<a href="http://technet.microsoft.com/en-us/library/jj134242)">http://technet.microsoft.com/en-us/library/jj134242)</a>, and I wanted to take an opportunity to explore some of what the help says - and perhaps offer an outsider&rsquo;s perspective.</p><h2 id="what-is-workflow" class="ps-heading">What is Workflow?<a class="ps-heading-anchor" href="#what-is-workflow" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Workflow is a set of technologies included with PowerShell v3, and is available on any computer running v3 (which can include Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows 8, and Windows Server 2012). A workflow is a special kind of PowerShell script that looks a lot like a function. When run, however, PowerShell translates the workflow to Windows Workflow Foundation (WWF) code, and hands it off to WWF to execute. That means the contents of a workflow are a bit different than the contents of a script.</p><h2 id="when-might-you-use-workflow" class="ps-heading">When might you use workflow?<a class="ps-heading-anchor" href="#when-might-you-use-workflow" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>This is where I take issue with the help files, a bit. They state:</p><blockquote><p>In general, you should consider using a workflow instead of a cmdlet or script when you must meet any of the following requirements.</p><ul><li>You need to perform a long-running task that combines multiple steps in a sequence.</li><li>You need to perform a task that runs on multiple devices.</li><li>You need to perform a task that requires checkpointing or persistence.</li><li>You need to perform a long-running task that is asynchronous, restartable, parallelizable, or interruptible.</li><li>You need to run a task on a large scale, or in high availability environments, potentially requiring throttling and connection pooling.</li></ul></blockquote><p>I don&rsquo;t think that&rsquo;s an accurate list. I think it&rsquo;s incomplete, for one, and I think it includes some things it shouldn&rsquo;t. Understand that workflow is _complicated. _These things require some up-front planning. Not every PowerShell command can be used natively in a workflow (despite what the help files imply), because not every command has a WWF equivalent. For me, workflow is something you should use <em>when no other, simpler mechanism</em> will meet your specific needs. This list in the help file is supposed to help you identify situations where workflow is <em>the only way to go</em> - but I think it&rsquo;s a bit misleading.<br>
Let&rsquo;s look at why.</p><h3 id="you-need-to-perform-a-long-running-task-that-combines-multiple-steps-in-a-sequence" class="ps-heading">You need to perform a long-running task that combines multiple steps in a sequence.<a class="ps-heading-anchor" href="#you-need-to-perform-a-long-running-task-that-combines-multiple-steps-in-a-sequence" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>Well, that&rsquo;s what a script does. Any script. Just because you need to run multiple steps in a sequence doesn&rsquo;t mean you should be using workflow.</p><h3 id="you-need-to-perform-a-task-that-runs-on-multiple-devices" class="ps-heading">You need to perform a task that runs on multiple devices.<a class="ps-heading-anchor" href="#you-need-to-perform-a-task-that-runs-on-multiple-devices" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>OK, workflow <em>can</em> do this, but so can the much easier-to-use Invoke-Command. Give it a command, or even a script, and you can run multiple steps, in a sequence, on multiple devices. Understand that workflow _uses _remoting to talk to remote devices; if you&rsquo;re using workflow, you&rsquo;ve already enabled remoting - so why not use it when the need is simpler?</p><h3 id="you-need-to-perform-a-long-running-task-that-is-asynchronous-restartable-parallelizable-or-interruptible" class="ps-heading">You need to perform a long-running task that is asynchronous, restartable, parallelizable, or interruptible.<a class="ps-heading-anchor" href="#you-need-to-perform-a-long-running-task-that-is-asynchronous-restartable-parallelizable-or-interruptible" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>It&rsquo;s really the &ldquo;or&rdquo; I have a problem with here. PowerShell jobs will let you run tasks asynchronously, and in parallel; restartable and interruptible are legitimate workflow-only features. If you need those, you need workflow; if you <em>merely</em> need asynchronous, consider using a job.</p><h3 id="you-need-to-run-a-task-on-a-large-scale-or-in-high-availability-environments-potentially-requiring-throttling-and-connection-pooling" class="ps-heading">You need to run a task on a large scale, or in high availability environments, potentially requiring throttling and connection pooling.<a class="ps-heading-anchor" href="#you-need-to-run-a-task-on-a-large-scale-or-in-high-availability-environments-potentially-requiring-throttling-and-connection-pooling" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>I don&rsquo;t see why Invoke-Command, which supports throttling of connections, couldn&rsquo;t accomplish this criteria. I&rsquo;ll admit that this one&rsquo;s borderline for me; because workflows are executed by WWF and not by PowerShell per se, it&rsquo;s probably better at scale-out. But I wouldn&rsquo;t<em>immediately</em> head for workflow just because I needed to run some command on a few thousand machines. I might, after further evaluation of the situation, select workflow after all - but it&rsquo;s not an automatic for me.</p><h3 id="you-need-to-perform-a-task-that-requires-checkpointing-or-persistence" class="ps-heading">You need to perform a task that requires checkpointing or persistence.<a class="ps-heading-anchor" href="#you-need-to-perform-a-task-that-requires-checkpointing-or-persistence" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>Truth. This is unique to workflow. As WWF executes your workflow tasks, it &ldquo;checkpoints&rdquo; its status to disk. That way, if the entire environment crashes, WWF can resume where it left off when things are rebooted. If you need this, it&rsquo;s a legitimate reason to head straight for workflow. And for a very long-running task with multiple steps _that might well be interrupted, _this would drive me right to workflow every time.</p><h3 id="you-need-to-perform-a-task-that-combines-steps-which-can-be-run-in-parallel-with-those-which-must-be-run-sequentially" class="ps-heading">You need to perform a task that combines steps which can be run in parallel with those which must be run sequentially<a class="ps-heading-anchor" href="#you-need-to-perform-a-task-that-combines-steps-which-can-be-run-in-parallel-with-those-which-must-be-run-sequentially" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h3><p>This is really a unique workflow thing, and one that isn&rsquo;t listed in the help files. Workflow can designate specific chunks - <em>activities</em> is the term workflow uses - that contain commands which must be run in a strict sequence, and designate other chunks to be run in parallel, in any particular order. This can massively improve performance, and is one of the main advantages that would push me to use workflow over an ordinary script.</p><h2 id="features-vs-drivers" class="ps-heading">Features vs. Drivers<a class="ps-heading-anchor" href="#features-vs-drivers" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>For me, this discussion is about workflow <em>features</em> - things it can do - versus workflow <em>drivers</em> - reasons you&rsquo;d use workflow and workflow alone. My last two points - checkpointing and persistence, along with parallel/sequential mixing - are the main workflow <em>drivers</em> for me. The ability to target multiple machines is a _feature; _something I can do with workflow once I&rsquo;ve decided to use it.<br>
To be fair, I&rsquo;m simplifying things a bit. Workflow&rsquo;s ability to target multiple machines in parallel may be more robust that remoting&rsquo;s ability to do so; I haven&rsquo;t tested that. Under the hood, though, I know that workflow <em>relies on remoting</em> for communications, so I suspect the two would perform similarly.</p><h2 id="hey-i-think-workflow-is-cool" class="ps-heading">Hey, I Think Workflow is Cool!<a class="ps-heading-anchor" href="#hey-i-think-workflow-is-cool" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Don&rsquo;t get me wrong. As I&rsquo;ve outlined above, there are definitely reasons I&rsquo;d choose to use workflow. But those aren&rsquo;t necessarily the reasons given by the help file. While I appreciate the time and effort Microsoft has put into workflow, I think they&rsquo;re a wee bit over-enthusiastic when suggesting that &ldquo;you should use a workflow when you have a task that combines multiple steps in a sequence.&rdquo; Workflow is a challenging technology, with a fairly steep learning curve. As yet, troubleshooting and debugging tools are scant. I&rsquo;ll stick with simpler mechanisms when they meet my needs - and aim for workflow when I need some of the amazing things that it alone can do for me.<br>
My concern with the help files is that they could drive relative newcomers to workflow by giving them the impression that it was the only way to achieve some of those things, or was the preferred way of achieving them. Those newcomers could easily be intimidated by workflow (heck, I still am), and just walk away from PowerShell entirely, not realizing that there were other, simpler ways of &ldquo;performing a task that runs on multiple devices.&rdquo; Help files like this should provide direction and guidance&hellip; and I just think in this case that the guidance oversells workflow a teeny bit.<br>
I&rsquo;ve sent a longer, more detailed version of this feedback to Microsoft as well. Perhaps the help files can evolve over time (hey, that&rsquo;s why PowerShell v3 has updatable help!) to provide better, more accurate guidance on when you <em>should</em> use workflow over some other approach.</p>
]]></content:encoded></item><item><title>eBook: Secrets of PowerShell Remoting</title><link>https://powershell.org/articles/2012-08-06-ebook-secrets-of-powershell-remoting/</link><guid>https://powershell.org/articles/2012-08-06-ebook-secrets-of-powershell-remoting/</guid><pubDate>Mon, 06 Aug 2012 19:22:35 +0000</pubDate><description>&lt;p&gt;This is a free e-book that covers PowerShell Remoting. There&amp;rsquo;s a brief overview and tutorial of actually using Remoting, but that part isn&amp;rsquo;t in-depth. What this e-book provides, that you won&amp;rsquo;t find elsewhere, is step-by-step, screenshot-based instructions for configuring Remoting for any imaginable scenario. You&amp;rsquo;ll also find troubleshooting tutorials and examples, and even information on how to explain Remoting to your corporate IT security team. It&amp;rsquo;s all the stuff that isn&amp;rsquo;t documented in PowerShell&amp;rsquo;s own help - and it&amp;rsquo;s completely free. You don&amp;rsquo;t even need to register to download the file!&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>This is a free e-book that covers PowerShell Remoting. There&rsquo;s a brief overview and tutorial of actually using Remoting, but that part isn&rsquo;t in-depth. What this e-book provides, that you won&rsquo;t find elsewhere, is step-by-step, screenshot-based instructions for configuring Remoting for any imaginable scenario. You&rsquo;ll also find troubleshooting tutorials and examples, and even information on how to explain Remoting to your corporate IT security team. It&rsquo;s all the stuff that isn&rsquo;t documented in PowerShell&rsquo;s own help - and it&rsquo;s completely free. You don&rsquo;t even need to register to download the file!</p><p>Current version: August 2012.</p><p>The ZIP file contains a PDF. We&rsquo;re not currently offering MOBI or EPUB versions of the file, as the conversion from DOCX using the tools we have available to us takes a zillion steps and is less than perfect. Please<a href="http://concentratedtech.com/contact/">contact Don directly through his Web site</a> if you&rsquo;re interesting in volunteering to help with format conversions.<br><a href="https://powershell.org/ebooks">Download Secrets of PowerShell Remoting</a></p>]]></content:encoded></item></channel></rss>