&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 2016 on PowerShell.org - Welcome Automaters!</title><link>https://powershell.org/articles/2016/08/</link><description>Recent content in Articles from August 2016 on PowerShell.org - Welcome Automaters!</description><generator>Hugo</generator><language>en-us</language><atom:link href="https://powershell.org/articles/2016/08/index.xml" rel="self" type="application/rss+xml"/><item><title>Ultimate PowerShell Prompt Customization and Git Setup Guide</title><link>https://powershell.org/articles/2016-08-26-ultimate-powershell-prompt-customization-and-git-setup-guide/</link><guid>https://powershell.org/articles/2016-08-26-ultimate-powershell-prompt-customization-and-git-setup-guide/</guid><pubDate>Fri, 26 Aug 2016 05:25:27 +0000</pubDate><description>&lt;p&gt;Do you spend hours a day in PowerShell? Switching back and forth between PowerShell windows getting you down? Have you ever wanted &amp;ldquo;Quake&amp;rdquo; mode for your terminal?&lt;br&gt;
If we are going to spend so much time in PowerShell, we may as well make it pretty.&lt;br&gt;
&lt;img src="https://hodgkins.io/images/posts/windows_git/sexy_powershell_prompt.png" alt=""&gt;&lt;br&gt;
Check out the &lt;a href="https://hodgkins.io/ultimate-powershell-prompt-and-git-setup"&gt;Ultimate PowerShell Prompt Customization and Git Setup Guide&lt;/a&gt; for how to:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Install and customize ConEmu&lt;/li&gt;
&lt;li&gt;Enable Quake Mode for your terminal&lt;/li&gt;
&lt;li&gt;Setup your PowerShell Profile&lt;/li&gt;
&lt;li&gt;Install and use Posh-Git&lt;/li&gt;
&lt;li&gt;Generate and use SSH Keys with GitHub&lt;/li&gt;
&lt;li&gt;Squash Git commits&lt;/li&gt;
&lt;/ul&gt;</description><content:encoded>&lt;![CDATA[<p>Do you spend hours a day in PowerShell? Switching back and forth between PowerShell windows getting you down? Have you ever wanted &ldquo;Quake&rdquo; mode for your terminal?<br>
If we are going to spend so much time in PowerShell, we may as well make it pretty.<br><img src="https://hodgkins.io/images/posts/windows_git/sexy_powershell_prompt.png" alt=""><br>
Check out the <a href="https://hodgkins.io/ultimate-powershell-prompt-and-git-setup">Ultimate PowerShell Prompt Customization and Git Setup Guide</a> for how to:</p><ul><li>Install and customize ConEmu</li><li>Enable Quake Mode for your terminal</li><li>Setup your PowerShell Profile</li><li>Install and use Posh-Git</li><li>Generate and use SSH Keys with GitHub</li><li>Squash Git commits</li></ul>
]]></content:encoded></item><item><title>Here's Another Reason to Contribute</title><link>https://powershell.org/articles/2016-08-24-heres-another-reason-to-contribute/</link><guid>https://powershell.org/articles/2016-08-24-heres-another-reason-to-contribute/</guid><pubDate>Wed, 24 Aug 2016 11:30:14 +0000</pubDate><description>&lt;p&gt;&lt;a href="http://Http://twitter.com/thejasonhelmick"&gt;Jason Helmick&lt;/a&gt; and I were talking last night, and we got onto the topic of expertise and respect. Kind of, &amp;ldquo;once someone really gets to that expert level, and they surpass their teacher in knowledge, you really respect them.&amp;rdquo; I disagreed, and said, &amp;ldquo;no, I respect them the minute they start contributing to the world, and helping others.&amp;rdquo;&lt;br&gt;
We all, at some stage, get &amp;ldquo;outsider syndrome,&amp;rdquo; where we think everyone else is so much smarter than us, that we&amp;rsquo;ve nothing of value to contribute. But that&amp;rsquo;s never true. First of all, there&amp;rsquo;s this thing called a &amp;ldquo;birth rate,&amp;rdquo; meaning there&amp;rsquo;s always new people coming into the field. Second, no matter what your level of expertise, you&amp;rsquo;re &lt;em&gt;in it, right then.&lt;/em&gt; &amp;ldquo;Experts&amp;rdquo; too often forget what it was like to be a beginner; a beginner &lt;em&gt;knows,&lt;/em&gt; and can often relate things that another beginner can understand more readily.&lt;br&gt;
Take this &lt;a href="https://powershell.org/2016/08/23/microsoft-did-what/"&gt;wonderful post by Missy&lt;/a&gt; Januszco. Missy probably doesn&amp;rsquo;t consider herself an expert, although she certainly held her own at my recent DevOps Camp. And she certainly wasn&amp;rsquo;t the only one writing about open-source, cross-platform PowerShell Core that week. But she did it from a unique perspective, one that a lot of her readers can probably take a lot from. And she &lt;em&gt;did it -&lt;/em&gt; instead of just talking vaguely about giving back someday, she just did, and did it well.&lt;br&gt;
PowerShell.org isn&amp;rsquo;t a curated newsfeed for a select few; its &lt;em&gt;yours&lt;/em&gt;. So if you don&amp;rsquo;t have your own place to publish and share, email webmaster@ and let us set you up to write. Whenever you solve some problem, conquer some gotcha, or have a perspective on the latest PowerShell news, share. You &lt;strong&gt;definitely&lt;/strong&gt; have something to offer.&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p><a href="http://Http://twitter.com/thejasonhelmick">Jason Helmick</a> and I were talking last night, and we got onto the topic of expertise and respect. Kind of, &ldquo;once someone really gets to that expert level, and they surpass their teacher in knowledge, you really respect them.&rdquo; I disagreed, and said, &ldquo;no, I respect them the minute they start contributing to the world, and helping others.&rdquo;<br>
We all, at some stage, get &ldquo;outsider syndrome,&rdquo; where we think everyone else is so much smarter than us, that we&rsquo;ve nothing of value to contribute. But that&rsquo;s never true. First of all, there&rsquo;s this thing called a &ldquo;birth rate,&rdquo; meaning there&rsquo;s always new people coming into the field. Second, no matter what your level of expertise, you&rsquo;re<em>in it, right then.</em> &ldquo;Experts&rdquo; too often forget what it was like to be a beginner; a beginner<em>knows,</em> and can often relate things that another beginner can understand more readily.<br>
Take this<a href="https://powershell.org/2016/08/23/microsoft-did-what/">wonderful post by Missy</a> Januszco. Missy probably doesn&rsquo;t consider herself an expert, although she certainly held her own at my recent DevOps Camp. And she certainly wasn&rsquo;t the only one writing about open-source, cross-platform PowerShell Core that week. But she did it from a unique perspective, one that a lot of her readers can probably take a lot from. And she<em>did it -</em> instead of just talking vaguely about giving back someday, she just did, and did it well.<br>
PowerShell.org isn&rsquo;t a curated newsfeed for a select few; its<em>yours</em>. So if you don&rsquo;t have your own place to publish and share, email webmaster@ and let us set you up to write. Whenever you solve some problem, conquer some gotcha, or have a perspective on the latest PowerShell news, share. You<strong>definitely</strong> have something to offer.</p>
]]></content:encoded></item><item><title>Microsoft did WHAT?</title><link>https://powershell.org/articles/2016-08-23-microsoft-did-what/</link><guid>https://powershell.org/articles/2016-08-23-microsoft-did-what/</guid><pubDate>Tue, 23 Aug 2016 01:51:05 +0000</pubDate><description>&lt;p&gt;Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.&lt;br&gt;
Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.&lt;br&gt;
But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.&lt;br&gt;
From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!&lt;br&gt;
&lt;a href="https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux"&gt;https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux&lt;/a&gt;&lt;br&gt;
&lt;a href="https://www.pluralsight.com/courses/linux-networking-advanced-lfce"&gt;https://www.pluralsight.com/courses/linux-networking-advanced-lfce&lt;/a&gt;&lt;br&gt;
I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>Unless you’ve been living under a rock for the last couple of days, you already know that Microsoft announced last Thursday that the shell/scripting language formerly known as “Windows Powershell” is now supported on Linux and MacOS and that Powershell has been open-sourced. And for days, thoughts of “how can I use this?” or “I wonder if ‘x’ will be supported” have been flying through the minds of every system architect as we internally grapple with the possibilities of what could be, while at the same time trying to understand Microsoft’s motivation for this radical change.<br>
Only the change isn’t so surprising if you think about the changes that Microsoft has been making leading up to this announcement. Separating Powershell Desktop Edition and Core Edition in WMF 5.1. Announcing SQL Server on Linux – after all, IT professionals are going to need a way to administer that SQL instance and it isn’t going to be through a GUI. Supporting Powershell on Linux seemed like a logical next step.<br>
But it is likely just a step along the road to heterogeneous system management. Microsoft Technical Fellow and Powershell inventor Jeffrey Snover isn’t at all secretive over the fact that the vision is built upon Microsoft’s Operations Management Suite (OMS), a suite of automation and management tools that needs to be able to configure, control, manage, monitor, and self-heal a workload that runs anywhere and on any operating system.<br>
From the perspective of a system architect that isn’t typically on the bleeding edge of technology, I am still extremely excited over this announcement. Why? The possibilities seem endless. For one, applications that run on either Windows or Linux or a combination of the two can now be configured by the same language, or maybe even the same set of well-designed scripts. Second, the possibility of using Desired State Configuration (DSC), or third-party tooling such as Chef or Puppet in conjunction with DSC, means I can keep *all* servers in compliance with their configurations using the same tooling. Third, what Devops engineer wouldn’t love having spent a few years learning a scripting language like Powershell only to have its reach extended to other platforms? This change invariably makes us more valuable to the company by being able to take on additional management responsibilities by using the skills we already have. It can then lead to even more cross-platform learnings and opportunities. I definitely plan to learn more about Linux and how I can help build cross-platform tools. If you have similar interests, here are some great resources to get you started!<br><a href="https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux">https://www.pluralsight.com/courses/essential-tools-red-hat-enterprise-linux</a><br><a href="https://www.pluralsight.com/courses/linux-networking-advanced-lfce">https://www.pluralsight.com/courses/linux-networking-advanced-lfce</a><br>
I haven’t even scratched the surface of thinking about all of the ways I want to take advantage of Powershell on Linux, and I have lots of exploring to do to find out what can or can’t be done – but the energy of the entire Powershell community over these changes certainly carries over to me as well. I’m excited to find out what is possible, to build what may not have been possible, and to contribute back to the Powershell community. So kudos to you, “new Microsoft”, for energizing the entire community of Powershell enthusiasts. I can’t wait to see what’s next.</p>
]]></content:encoded></item><item><title>Why "Objects," Remoting, and Consistency are Such a Big Deal in PowerShell</title><link>https://powershell.org/articles/2016-08-22-why-objects-remoting-and-consistency-are-such-a-big-deal-in-powershell/</link><guid>https://powershell.org/articles/2016-08-22-why-objects-remoting-and-consistency-are-such-a-big-deal-in-powershell/</guid><pubDate>Mon, 22 Aug 2016 20:39:49 +0000</pubDate><description>&lt;p&gt;As PowerShell begins to move into a cross-platform world, it&amp;rsquo;s important to really understand &amp;ldquo;why PowerShell.&amp;rdquo; What is it, exactly, that sets PowerShell apart? Notice that I do not mean, &amp;ldquo;what makes it better,&amp;rdquo; because &amp;ldquo;better&amp;rdquo; is something you&amp;rsquo;ll have to decide on your own. I just want to look at what makes it _different. _&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>As PowerShell begins to move into a cross-platform world, it&rsquo;s important to really understand &ldquo;why PowerShell.&rdquo; What is it, exactly, that sets PowerShell apart? Notice that I do not mean, &ldquo;what makes it better,&rdquo; because &ldquo;better&rdquo; is something you&rsquo;ll have to decide on your own. I just want to look at what makes it _different. _</p><h2 id="its-the-objects" class="ps-heading">It&rsquo;s the Objects<a class="ps-heading-anchor" href="#its-the-objects" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Folks often say that Linux is a text-based OS, whereas Windows is an object-based OS. That&rsquo;s a convenient simplification, but it isn&rsquo;t exactly accurate. And to understand why PowerShell is different, you need to understand the <em>actual</em> differences - and how Linux and Windows have actually come closer together over the years.<br>
*nix - including Unix, macOS, and Linux - is based on very old concepts. &ldquo;Old&rdquo; isn&rsquo;t &ldquo;bad&rdquo; at all; much of Linux&rsquo; current flexibility comes from these old concepts. Core to the Unix ethos is the fact that OS configurations come from text files. There&rsquo;s no Registry, there&rsquo;s no database, it&rsquo;s just text files. Kinda like, um, Windows was, back in the old days, with .ini files (and where do you think the idea for those came from). Text files are super-easy to view, search, modify, and so on. Heck, when I wrote my first Point of Sale system, it was largely text-based, because text files were super-easy for us to troubleshoot remotely, compared to a complex ISAM table structure.<br>
Windows, on the other hand, is an API-based operating system. When you want to query an OS configuration element, you don&rsquo;t just look in a text file - you run code, and query an API. When you need to make a change, you don&rsquo;t just change a text file and hup a daemon - you run code, and submit your changes to an API.<br>
When you need to pass data from one hunk of code to another, you need to have an agreed-upon structure for that data, so that the code on both ends understands the data. These structures are called _objects. _Traditionally, Unix didn&rsquo;t really have structured data. The file format used by Apache for its configuration was different from the format used by Iptables. Which is totally fine, by the way, because those two things never need to talk to each other. But when you start considering all the things the OS can do - users, file permissions, groups, ports, you name it - you started to end up with a lot of different formats. Indeed, the main reason that Unix had (has?) a reputation for being a complex OS to administer is largely because all of its data is scattered hither and yon, and all in different formats.<br>
That&rsquo;s been changing, though. You&rsquo;re starting to see more and more new projects pop up that rely on <em>structured</em> configuration data, often using JavaScript Object Notation (JSON), although in other cases something like XML. This is a big deal for *nix administration. Why?<br>
Traditionally, re-using the output of a Unix command was complex. Output was pure text, sent to your console via the stdout &ldquo;channel.&rdquo; Commands typically formatted their output for human eyeball consumption, so if you wanted to send that output instead to another command, you had to do a lot of text parsing. &ldquo;Skip the first two rows of output, and then for each remaining row, go over 32 columns and grab 5 columns worth of text.&rdquo; Or, &ldquo;skip the first row, and then in each subsequent row, look for text matching this [regex] and return only the matching text.&rdquo; Unix admins tend to <em>own</em> regular expressions for this reason.<br>
But the problem with all that is that your workflow, and your tooling, becomes very version-bound. Nobody can ever improve tools like <strong>ps</strong>, because so many scripts rely on the output being exactly as it is today. Instead, you create entire new versions of those tools - which people then take dependencies on, and which can then never change, unless they provide some backward-compatibility switches to force old-version output. The end result is a highly fragmented landscape of tooling, a very high learning curve for incoming administrators, and a high amount of overhead in automating business processes.<br>
When you code a command-line utility in 1973, it&rsquo;s easy to imagine it&rsquo;ll never need to change. On the other hand, when you start building APIs in the 1990s, it&rsquo;s much more obvious that change will be constant. By passing objects - structured data - between themselves, APIs provide a kind of inbuilt forward-compatibility. If v1 of an API outputs objects that have 10 properties, v2 can easily add five more without breaking anything downstream. Anything consuming those objects won&rsquo;t care if there&rsquo;s extra data, so long as the data it was expecting is all there. Object-based data doesn&rsquo;t have any sense of &ldquo;ordering,&rdquo; so it doesn&rsquo;t matter if the &ldquo;first&rdquo; property is Name or if the &ldquo;first&rdquo; property is Size. Consumers refer to properties by name, not by position, and the magic of the API itself makes it all match up.<br>
Objects also lend themselves to hierarchies of data. A computer object can have a Drives property, which can be a collection of Drive objects, which can have a Files property, which is a collection of File objects, and so on. Structured data like XML and JSON handle these hierarchies with ease, as do object-oriented APIs; textual output - which is essentially a flat-file at best - doesn&rsquo;t.<br>
So what sets PowerShell apart from other shells is the fact that its commands pass objects from one to another. When you reach the end of a &ldquo;chain,&rdquo; or pipeline, of commands, the shell takes what&rsquo;s left and generates textual output suitable for human eyeball consumption. So you get the advantages of a text-based command - easy to read output - and the advantages of working with an API. For example, in PowerShell for Linux, Microsoft ships a command that wraps around the Cron feature. Cron is configured from a text file; Microsoft&rsquo;s command &ldquo;understands&rdquo; the text file format, and turns it into objects. That means nobody will ever have to grep/sed/awk that text file again - instead, you can deal with structured data. That&rsquo;s a really good example of taking something PowerShell is good at - objects - and applying it to something Linux is really good at - Cron. It&rsquo;s not forcing Cron to look like the Windows Task Scheduler in any way; it&rsquo;s simply applying a new shell paradigm to an already-solid OS component.<br>
This concept of a shell passing objects - again, just structured data - was unique enough that Microsoft was<a href="http://appft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&amp;Sect2=HITOFF&amp;d=PG01&amp;p=1&amp;u=%2Fnetahtml%2FPTO%2Fsrchnum.html&amp;r=1&amp;f=G&amp;l=50&amp;s1=%2220050091201%22.PGNR.&amp;OS=DN/20050091201&amp;RS=DN/20050091201">granted a patent</a> for it (the patent also includes other innovations).</p><h2 id="remoting" class="ps-heading">Remoting<a class="ps-heading-anchor" href="#remoting" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>The parent also touches on _remoting, _which was equally innovative. Yes, I know that Unix has <em>forever</em> had the ability to log into a remote machine, first using things like Telnet, later SSH, and even later still more things. But that&rsquo;s _remote logon, _and it&rsquo;s not Remoting.<br>
With remote logon, you&rsquo;re essentially turning your local computer into a dumb terminal for a remote computer, a concept literally as old as computers themselves. It&rsquo;s a 1:1 connection, and it was fine when a given company didn&rsquo;t have more than a few machines. But modern, cloud-based architecture involves <em>thousands</em> of machines, and 1:1 doesn&rsquo;t cut it. Remoting enables 1:many connections - &ldquo;here is a command; go tell these 1200 computers to run it individually, using their own local resources, and then send me the results - as objects.&rdquo; Going forward, PowerShell can use either WS-MAN or SSH as the low-level transport for that conversation, but the protocol isn&rsquo;t important. It&rsquo;s the idea of running one command _locally, _piping that output to another command _which runs remotely, _and then taking <em>that</em> output and piping it to yet more commands that run _locally. _This mixing-and-matching of computing resources and runtime locations is _huge. _</p><h2 id="consistency" class="ps-heading">Consistency<a class="ps-heading-anchor" href="#consistency" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>And finally, the one argument that&rsquo;s the toughest to make. Plenty of *nix admins, and plenty of old-school MS-DOS command-line admins, take great pride in their mastery of obscure command-line syntax. It sets them apart from lesser humans, provides a veneer of job security, and proves their dominance of their field.<br>
Unfortunately, it&rsquo;s bad for the planet.<br>
Look, maybe your country is in fine economic shape (_ahem, _Norway), but here in the United States we have a fairly precarious hold on Biggest Economy in the World. We aren&rsquo;t a manufacturing powerhouse. We basically have two experts: information technology and Hollywood, and we&rsquo;re sometimes sorry about the latter. But for our economy to thrive in this century, we need all hands on deck when it comes to IT. That means a high barrier of entry, and the need to memorize arbitrary and obscure syntax, ain&rsquo;t gonna cut it. Computing is hard enough without making it artificially more obscure through syntax.</p><p><code>chmod ugo+rwx sample.sh</code>Yeah, see, that&rsquo;s too hard to teach a 12-year-old.</p><p><code>Set-FilePermission -FileName sample.sh -Permissions Read,Write,Execute -Principal User,Group,Others -Action Add</code>See, you still need to know <em>what&rsquo;s going on</em> in both cases, but the syntax is much easier to read and understand without having to look it up. The command syntax becomes less obscure, and more self-documenting. More maintainable. Obviously, this is just a bogus example, but it illustrates the <em>pattern</em> of PowerShell - meaningful command names, meaningful parameter names, and meaningful parameter value enumerations. And I use <em>meaningful</em> in the correct way, as in, &ldquo;full of meaning.&rdquo;<br>
PowerShell still allows for a shorthand syntax, if you&rsquo;re just in a hurry -</p><p><code>sfp sample.sh -p r,w,x -for u,g,o -a add</code>- but you&rsquo;re not forced into it, and it&rsquo;s easier to figure out what those things mean (again, this is a bogus example meant to show the shell&rsquo;s syntax pattern, not an actual run-able command).</p><h2 id="so-thats-the-big-deal" class="ps-heading">So&hellip; that&rsquo;s the big deal<a class="ps-heading-anchor" href="#so-thats-the-big-deal" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>And so that&rsquo;s what makes PowerShell _different. _It&rsquo;s not going to obviate Bash on Linux anytime soon, although it&rsquo;s happy to let you run your same old text-based commands, and even integrate their output as best it can into its object-based pipeline. But at least now, anyone approaching PowerShell for the first time can understand _what makes it different, _and decide for themselves if they think that&rsquo;s worth an investment to learn to use PowerShell well.</p>]]></content:encoded></item><item><title>Create Custom Monitors with PowerShell</title><link>https://powershell.org/articles/2016-08-21-create-custom-monitors-with-powershell/</link><guid>https://powershell.org/articles/2016-08-21-create-custom-monitors-with-powershell/</guid><pubDate>Sun, 21 Aug 2016 23:44:53 +0000</pubDate><description>&lt;p&gt;Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run &lt;em&gt;Get-Foo&lt;/em&gt; to check details about the &lt;em&gt;foo&lt;/em&gt; resource. And then you come back 5 minutes later and run it again because you want to see how it changes over time.&lt;br&gt;
But wouldn&amp;rsquo;t it be nice if you could just have it run automatically at regular intervals in a separate window that you could just keep in the corner of your screen? Well, I found the barebones of just such a utility sometime ago (authored by Marc van Orsouw,  aka ‘thePowerShellGuy’). His original post is no longer available, but I expanded upon his code and, over time, added features, bug fixes, and enhancements, making it more useful and more user-friendly. Here are a few screenshots of the Monitor Factory in action.&lt;br&gt;
&lt;em&gt;Monitor the size of a database&lt;/em&gt;&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>Sometimes, as a developer, you want to be be able to keep track of free space on a drive, the size of a log, the load on your CPU, the number of users logged in, etc. With PowerShell, it is typically just a matter of finding the right cmdlet amidst the large (and rapidly growing) pool of cmdlets provided by Microsoft and by third parties. Then you just run<em>Get-Foo</em> to check details about the<em>foo</em> resource. And then you come back 5 minutes later and run it again because you want to see how it changes over time.<br>
But wouldn&rsquo;t it be nice if you could just have it run automatically at regular intervals in a separate window that you could just keep in the corner of your screen? Well, I found the barebones of just such a utility sometime ago (authored by Marc van Orsouw,  aka ‘thePowerShellGuy’). His original post is no longer available, but I expanded upon his code and, over time, added features, bug fixes, and enhancements, making it more useful and more user-friendly. Here are a few screenshots of the Monitor Factory in action.<br><em>Monitor the size of a database</em></p><p><code>Start-Monitor -AsJob {</code>Invoke-Sqlcmd &lsquo;DBCC SQLPERF(logspace)&rsquo; |<code>Select-Object 'Database Name','Log Size (MB)','Log Space Used (%)',HasErrors</code>}
`<img src="https://powershell.org/wp-content/uploads/2016/08/monitor-db-size-1.jpg" alt="Database Size Monitor"><br><em>Monitor drives on a system</em><br><img src="https://powershell.org/wp-content/uploads/2016/08/monitor-file-size-1.jpg" alt="Drive Capacity Monitor"><br><em>Monitor longest running DB queries</em><br><img src="https://powershell.org/wp-content/uploads/2016/08/monitor-queries-1.jpg" alt="Long-runnning DB Query Monitor"><br><a href="https://www.simple-talk.com/sysadmin/powershell/build-your-own-resource-monitor-in-a-jiffy/">Build Your Own Resource Monitor in a Jiffy</a> reveals how quick and easy it is to get started with the Monitor Factory.</p>
]]></content:encoded></item><item><title>Why PowerShell on Linux is Such an Accomplishment</title><link>https://powershell.org/articles/2016-08-19-why-powershell-on-linux-is-such-an-accomplishment/</link><guid>https://powershell.org/articles/2016-08-19-why-powershell-on-linux-is-such-an-accomplishment/</guid><pubDate>Fri, 19 Aug 2016 15:36:08 +0000</pubDate><description>&lt;p&gt;Yesterday, Microsoft &lt;a href="https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/"&gt;announced&lt;/a&gt; that Windows PowerShell - which I suppose we&amp;rsquo;ll just call &amp;ldquo;PowerShell,&amp;rdquo; now - has been open-sourced, with PowerShell Core builds being made available for various Linux distros as well as macOS.&lt;br&gt;
This is a big deal, but not exactly for the reasons you might think.&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>Yesterday, Microsoft<a href="https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/">announced</a> that Windows PowerShell - which I suppose we&rsquo;ll just call &ldquo;PowerShell,&rdquo; now - has been open-sourced, with PowerShell Core builds being made available for various Linux distros as well as macOS.<br>
This is a big deal, but not exactly for the reasons you might think.</p><h2 id="that-net-shell-guy" class="ps-heading">That .NET Shell Guy<a class="ps-heading-anchor" href="#that-net-shell-guy" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>PowerShell&rsquo;s genesis goes back to 2002 - and even earlier, really - when Jeffrey Snover wrote &ldquo;<a href="https://www.google.com/url?sa=t&amp;rct=j&amp;q=&amp;esrc=s&amp;source=web&amp;cd=1&amp;cad=rja&amp;uact=8&amp;ved=0ahUKEwiRtrzc1M3OAhVD7GMKHVe8Cz4QFggcMAA&amp;url=https%3A%2F%2Fwww.gitbook.com%2Fbook%2Fdevopscollective%2Fthe-monad-manifesto-annotated%2Fdetails&amp;usg=AFQjCNEi5p7CeZIrvKWKovnnBb7zLpyCGw&amp;bvm=bv.129759880,d.cGc">The Monad Manifesto</a>.&rdquo; He was trying to take a top-down approach to solving a long-standing problem with Windows administration, one that VBScript and other approaches had failed to fully address.<br>
Problem was, Snover was proposing an administrative shell, and scripting language, _built on top of the .NET Framework. _That&rsquo;s not inherently a bad thing; tens of thousands of line-of-business applications have been written in .NET, and along with Java, it&rsquo;s probably one of the most popular business software frameworks on the planet. Thing is, Snover was suggesting this at a time when .NET Framework-based projects were failing left and right <em>inside</em> Microsoft. This was in the &ldquo;Longhorn&rdquo; timeframe, when projects like WinFS - touted as the very basis of a new generation of Windows - had epically failed to deliver. Microsoft wound up<a href="http://www.theregister.co.uk/2005/05/26/dotnet_longhorn/">&ldquo;decoupling&rdquo; Longhorn from .NET</a>, and now there&rsquo;s this loudmouth running around trying to build a <em>shell</em> on it?<br>
I won&rsquo;t say that Jeffrey was a pariah internally for a period of time, but he certainly had his battles to fight.<br>
And he won.</p><h2 id="the-powershell-era" class="ps-heading">The PowerShell Era<a class="ps-heading-anchor" href="#the-powershell-era" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Launching in 2006, PowerShell 1.0 was in many ways the &ldquo;minimal viable product&rdquo; the team could have shipped. Notably, it lacked Remoting, something which would hold PowerShell back until 2.0 shipped a couple of years later. But Snover and his team, with 1.0, still accomplished the near-unimaginable: they convinced the Exchange Server team to go all-in, and build an almost model implementation of how to use PowerShell for administration. Exchange Server 2007 built its very GUI on top of PowerShell, just as Snover had imagined in his Manifesto. It&rsquo;s perhaps hard to imagine, a decade later, how incredible an accomplishment this was for Microsoft. Exchange Server was very much the flagship product of the time. Pretty much everyone bought Exchange Server, and to make this big a flip was a big deal.<br>
To be sure. the Exchange Server team wasn&rsquo;t without their worries. In fact, the team hedged its bets in a big way. Rather than instrumenting the server directly in PowerShell, the team built an entire abstraction layer, and wrote PowerShell commands _to that. _That way, they reasoned, if this &ldquo;.NET Shell thing&rdquo; was a flop, they could rip it out and replace it with something else, and do so fairly quickly.<br>
PowerShell wasn&rsquo;t a flop.</p><h2 id="in-lockstep-with-the-vision" class="ps-heading">In Lockstep with the Vision<a class="ps-heading-anchor" href="#in-lockstep-with-the-vision" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Few realize it, but every version of PowerShell up to, and including, 4.0 were created in lockstep with the original Manifesto. While each version introduced a bevy of new features, the &ldquo;headline&rdquo; feature in each was taken straight from the Manifesto:</p><ol><li>A composable command-line shell and scripting language</li><li>Remoting</li><li>Workflow</li><li>Desired State Configuration</li></ol><p>Snover and the Windows Management Framework (WMF) team - of which PowerShell and its supporting technologies are a part - kept marching firmly in the direction he&rsquo;d outlined. And that&rsquo;s not to in any way suggest it was a one-man show. Luminaries like Bruce Payette, who led much of the core language development, helped make PowerShell accessible to newcomers and familiar-feeling to programming pros. Guys like Lee Holmes not only helpd move development forward, but more recently gave the shell a stronger security focus. Dozens of unseen and unsung heroes helped make sure PowerShell was meeting the needs of its audience (I&rsquo;m reminded by one exercise at a Microsoft MVP Summit, where MVPs helped reproduce and categorize filed bugs so that the team could start working through them, and another incident where Program Manager Dan Harman read through <em>hundreds</em> of suggestions in Microsoft Connect to help bring as many of them to life as possible). There are team members who&rsquo;ve been with the product for a decade, something that&rsquo;s nigh unheard-of in Microsoft.</p><h2 id="the-role-of-community" class="ps-heading">The Role of Community<a class="ps-heading-anchor" href="#the-role-of-community" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>The team knew at the outset that PowerShell <em>would</em> flop if people weren&rsquo;t using it, and becoming passionate about it. Numerous team members began to engage with the community on a regular basis to help that community come to life. The PowerShell MVPs - honestly, one of the most engaged and critical groups of MVPs within the MVP program - encouraged people to learn the shell, poke at it, and complain about any shortcomings they ran across. This vocal community made a serious impact. An early build of PowerShell 3.0 included a ReadMe file listing some 80-odd new features and changes, _along with the names of the people who&rsquo;d suggested them. _Snover himself remains a regular conference guest. Payette and Holmes wrote bestselling books. Numerous team members appeared at Microsoft TechEd and Ignite.<br>
And the team supported independent community efforts whenever possible. Managers like Kenneth Hansen, Angel Calvo, Erin Chapple, and more made sure community leaders had access to answers and resources when they needed them (scarce as those resources could be, at times), and the entire team worked to give as much of their time as possible to helping the independent community thrive. Sites like PowerShell.org and PowerShellMagazine.com,  the PowerScripting Podcast, and conferences like PowerShell Conference Asia, PowerShell Conference Europe, and the PowerShell + DevOps Global Summit would have been impossible without the generous support the team gave.<br>
And that community thrived. Perhaps the biggest &ldquo;wins&rdquo; came with Advanced Functions (affectionately called &ldquo;script cmdlets&rdquo;) and Desired State Configuration, where we no longer had to rely on Microsoft to provide us with the tools we needed, but could instead code them up ourselves.<br>
And<em>that</em> was a turning point.</p><h2 id="baby-open-source-steps" class="ps-heading">Baby Open Source Steps<a class="ps-heading-anchor" href="#baby-open-source-steps" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Understand that open source had long been the enemy at Microsoft. The company&rsquo;s attempts to fight back against Linux and establish a Windows-only datacenter created a culture that deeply distrusted open source, and in many ways regarded it as the opposite of what Microsoft was all about. But <em>many</em> within Microsoft regarded open source as a way to better provide customers with what they actually needed, and a way to empower customers to create their own solutions, rather than relying entirely on what Redmond could produce.<br>
The PowerShell team&rsquo;s first step into open source was to simply release the Desired State Configuration Resource Kit on GitHub. It wasn&rsquo;t a big step, as the Kit modules were all script anyway, making the source &ldquo;open&rdquo; kind of by default. That happened at almost the same time the company released an open-source (!) Local Configuration Manager implementation for Linux (!!). Satya was in charge now, after all, and he&rsquo;d made it clear that _Microsoft Loves Linux. _<br>
Not long after, Desired State Configuration&rsquo;s documentation was open-sourced (!!!) as a set of Markdown (!!!!) documents, allowing anyone to contribute and make corrections. That was quickly followed by <em>all</em> the PowerShell core documentation being open-sourced (!!!!!). Haters gonna hate, of course, and Microsoft was quickly accused by some as simply &ldquo;taking advantage&rdquo; of the community for &ldquo;free bug testing and documentation writing.&rdquo; Which, of course, is the <em>whole point</em> of the OSS movement. Customers were now _empowered. _We didn&rsquo;t have to wait for Microsoft to fix a typo, or file an expensive support incident. We could fork, fix, and submit a PR.<br>
Snover made it clear as far back as 2014 that the open-sourcing of PowerShell itself was &ldquo;inevitable,&rdquo; although he could never comment on a timeline. The blocker, he felt, was that .NET itself - which PowerShell runs on - was closed-source, making an open-source PowerShell fairly useless.</p><h2 id="the-dominoes-begin-to-fall" class="ps-heading">The Dominoes Begin to Fall<a class="ps-heading-anchor" href="#the-dominoes-begin-to-fall" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Of course, Microsoft recently open-sourced .NET Core, bringing it - and things like ASP.NET Core - to Linux and Mac. Suddenly, Snover&rsquo;s &ldquo;blocker&rdquo; wasn&rsquo;t a block. Well, kind of. PowerShell needed a lot more than .NET Core.<br>
Except for _PowerShell Core, _which was designed to run on the extremely stripped-down Nano Server version of Windows Server 2016. PowerShell Core ran on .NET Core. .NET Core was open-sourced.<br>
And so, yesterday, PowerShell itself followed into the world of open source. It&rsquo;s<a href="http://github.com/powershell/powershell">hosted on GitHub</a>, for pity&rsquo;s sake, which is about the most non-old-school-Microsoft thing I can imagine. And the first pull requests have already been submitted.<br>
But I want you to look back at where PowerShell has been these past 10+ years. It began as a simple document, and nearly didn&rsquo;t live, thanks to the negative internal feelings on .NET at the time. But it <em>did</em> live, thanks in part to a strong vision, and in part to a passionate team of designers and developers who knew their &ldquo;.NET shell&rdquo; would make a difference. Today, PowerShell is deeply embedded into nearly every Microsoft business product, and is becoming more so every day. All of this happened in about the same time it took VBScript to become widely accepted by administrators - but PowerShell, in that time, has come <em>leagues</em> further.</p><h2 id="sure-but-on-linux" class="ps-heading">Sure&hellip; but on<em>Linux</em>???<a class="ps-heading-anchor" href="#sure-but-on-linux" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Of course, none of the forgoing in any way explains why PowerShell on Linux (or macOS) makes any sense. These operating systems are inherently text-based, and their existing shells have been getting the job done for decades. So why PowerShell? Why now?<br>
First, I think it&rsquo;s telling that PowerShell on *nix (which includes, for me, macOS, based as it is on BSD) is _respectful. _On Windows, we have Unix-like aliases - ps, ls, and the like - which run PowerShell-equivalent commands. Not on *nix. Run <strong>ps</strong> and you&rsquo;ll get the same <strong>ps</strong> you&rsquo;ve always run; ditto with ls, man, and all the others. PowerShell isn&rsquo;t here to trample the commands you know. But it <em>can</em> integrate those commands into its pipeline, feeding them objects-as-text, and consuming the text they output. &ldquo;Objects&rdquo; simply being a defined data structure, many familiar Linux command-line compositions can be done more easily and in a more readable sense in PowerShell, since text manipulation is less critical. Command-lines become less fragile, too, since these data structures can remain the same even when the underlying command is updated. Leading up to the release of PowerShell on *nix, I had the opportunity to work with many die-hard Linux admins who, once they agreed to keep an open mind, started to really appreciate what PowerShell could do for them.<br>
And don&rsquo;t forget that _Microsoft Loves Linux. _Having a single shell experience, and cross-platform shell connectivity, makes it easier to run Windows and Linux _together. _It&rsquo;ll make it easier to manage Linux in Microsoft&rsquo;s Azure cloud. It gives us, the IT community, _options, _where before we didn&rsquo;t have any.<br>
And I think, tellingly, PowerShell on *nix represents a sea change at Microsoft. You&rsquo;re no longer being asked to buy into a single-stack solution. Microsoft&rsquo;s happy to let you mix and match as needed. Most importantly, they think you&rsquo;ll use their products - like PowerShell - because _they&rsquo;re the best tool for the job. <em>In other words, Microsoft&rsquo;s willing to <em>compete,</em> and have you use their products because you choose to, not because you&rsquo;ve been locked into them.</em> _That&rsquo;s a wonderful thing. There&rsquo;s the implied risk of losing the competition, but it&rsquo;s a risk Old Microsoft has tried to mitigate and remove as much as possible. Now, we have the option to use Office wherever we want - not tied to Windows. PowerShell is no longer tied exclusively to Windows. We&rsquo;re seeing that attitude work both ways, too, with Bash on Windows, SSH on Windows, and more. These products can <em>compete</em> for your attention, and that will make them<em>all</em> better products in the long run.<br>
So congratulations to Jeffrey Snover, to all the members of the Windows Management Framework team, and to Microsoft itself. And congratulations to PowerShell itself - and to the global community that brought us to this inevitable new beginning.</p>]]></content:encoded></item><item><title>FAQ: PowerShell on Linux/Mac</title><link>https://powershell.org/articles/2016-08-18-faq-powershell-on-linuxmac/</link><guid>https://powershell.org/articles/2016-08-18-faq-powershell-on-linuxmac/</guid><pubDate>Thu, 18 Aug 2016 21:02:51 +0000</pubDate><description>&lt;p&gt;&lt;em&gt;Be sure to check back often, as we&amp;rsquo;ll add to this.&lt;/em&gt;&lt;/p&gt;
&lt;h2 id="so-does-this-mean-ill-be-able-to-run-add-your-favorite-module-name-here-on-linuxmac" class="ps-heading"&gt;So does this mean I&amp;rsquo;ll be able to run [add your favorite module name here] on Linux/Mac?&lt;a class="ps-heading-anchor" href="#so-does-this-mean-ill-be-able-to-run-add-your-favorite-module-name-here-on-linuxmac" 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;Likely not. PowerShell on Linux/Mac is, at present, &amp;ldquo;PowerShell Core,&amp;rdquo; which is a subset of the total &lt;em&gt;Windows&lt;/em&gt; PowerShell product. Similar situation to PowerShell on Nano. So any module that requires something outside Core, won&amp;rsquo;t run.&lt;br&gt;
And further, most modules have dependencies on underlying technologies in Windows. The SMBShare module, for example, depends on CIM classes that only exist on Windows.&lt;br&gt;
So many add-in modules _won&amp;rsquo;t, _in fact work on Linux - because they&amp;rsquo;re designed to manage Windows machines. Over time, I&amp;rsquo;m sure we&amp;rsquo;ll see modules that only run on Linux and/or Mac, because they&amp;rsquo;re tied to dependencies on those operating systems.&lt;br&gt;
Ideally, of course, you can always remote to the OS of your choice and run whatever commands it has. And from &lt;a href="http://www.theregister.co.uk/2016/08/18/microsoft_brings_powershell_to_linux_and_mac_publishes_as_open_source/"&gt;The Register&lt;/a&gt;:&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p><em>Be sure to check back often, as we&rsquo;ll add to this.</em></p><h2 id="so-does-this-mean-ill-be-able-to-run-add-your-favorite-module-name-here-on-linuxmac" class="ps-heading">So does this mean I&rsquo;ll be able to run [add your favorite module name here] on Linux/Mac?<a class="ps-heading-anchor" href="#so-does-this-mean-ill-be-able-to-run-add-your-favorite-module-name-here-on-linuxmac" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Likely not. PowerShell on Linux/Mac is, at present, &ldquo;PowerShell Core,&rdquo; which is a subset of the total <em>Windows</em> PowerShell product. Similar situation to PowerShell on Nano. So any module that requires something outside Core, won&rsquo;t run.<br>
And further, most modules have dependencies on underlying technologies in Windows. The SMBShare module, for example, depends on CIM classes that only exist on Windows.<br>
So many add-in modules _won&rsquo;t, _in fact work on Linux - because they&rsquo;re designed to manage Windows machines. Over time, I&rsquo;m sure we&rsquo;ll see modules that only run on Linux and/or Mac, because they&rsquo;re tied to dependencies on those operating systems.<br>
Ideally, of course, you can always remote to the OS of your choice and run whatever commands it has. And from<a href="http://www.theregister.co.uk/2016/08/18/microsoft_brings_powershell_to_linux_and_mac_publishes_as_open_source/">The Register</a>:</p><blockquote><p>Vendors with PowerShell libraries for their products will be able to port them to the new Core version, and early examples are AWS (Amazon Web Services) and VMware. Steve Roberts, AWS Software Development Engineer, has shown the AWS Tools for PowerShell running on a Mac; and VMware&rsquo;s Alan Renouf has done a similar demonstration using vSphere PowerCLI. &ldquo;We’ve got commands that will manage every aspect of vCenter administration already,&rdquo; said Renouf.</p></blockquote><h2 id="snovers-blog-post-mentioned-remoting-over-ssh-so-does-that-mean-i-can-remote-into-any-linux-box" class="ps-heading">Snover&rsquo;s blog post mentioned Remoting over SSH. So does that mean I can Remote into any Linux box?<a class="ps-heading-anchor" href="#snovers-blog-post-mentioned-remoting-over-ssh-so-does-that-mean-i-can-remote-into-any-linux-box" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>No, not exactly. It&rsquo;s worth understanding, first, how the existing Remoting over WS-MAN works. In Remoting, you type or compose a command on one node. It is packaged into XML, and transmitted as text over the WS-MAN protocol. The receiving node unpackages it, runs the command, and <em>serializes</em> the resulting objects into XML. That XML is sent back, again over WS-MAN (which is based on HTTP), to the originating node. The originating node _deserializes _the XML to recreate the original objects.<br>
Remoting over SSH will work exactly the same way, except that SSH will be used to transmit the XML text back and forth, rather than WS-MAN. This isn&rsquo;t the same as a simple SSH session where you&rsquo;re just sending keystrokes to the remote machine. A &ldquo;plain&rdquo; Linux machine&rsquo;s SSH daemon wouldn&rsquo;t know what to do with the XML-packaged traffic used by Remoting. Remoting over SSH will require both nodes to be running PowerShell. SSH isn&rsquo;t the end-game, here; it&rsquo;s merely being used to get text from one place to another. This isn&rsquo;t &ldquo;PowerShell SSH-ing into a remote machine,&rdquo; either. PowerShell isn&rsquo;t an SSH client or server, in that sense.<br>
Microsoft has already said they plan to release an SSH server and client for Windows. <em>That</em> will get you the plain-Jane SSH interactive sessions that you&rsquo;re used to. SSH, in that scenario, works a lot like encrypted Telnet (it&rsquo;s based on Telnet, after all, as is nearly every other Internet protocol). You press a letter on your keyboard, and it&rsquo;s sent to the remote machine, which then echoes it back to you, so the letter also appears on your local console. When you hit enter to run a command, the text output is sent to your console. &ldquo;Plain&rdquo; SSH is a purely text-based thing - while PowerShell&rsquo;s strengths come from its use of objects, rather than text.<br>
So it&rsquo;s important to differentiate, in your mind, &ldquo;using SSH the way I&rsquo;m used to&rdquo; and &ldquo;Remoting using SSH as a text transport.&rdquo; There&rsquo;s actually precedent for what Remoting is doing: SCP. SCP encodes binary files as a text stream (vaguely like SMTP does), and uses SSH to transmit that text. It&rsquo;s then decoded into the original binary on the other end. But although SCP <em>uses</em> SSH under the hood, we certainly don&rsquo;t think of it as &ldquo;using SSH&rdquo; the way we do when we have an interactive SSH login on a remote box.</p>
]]></content:encoded></item><item><title>PowerShell is Open Sourced</title><link>https://powershell.org/articles/2016-08-18-powershell-is-open-sourced/</link><guid>https://powershell.org/articles/2016-08-18-powershell-is-open-sourced/</guid><pubDate>Thu, 18 Aug 2016 16:05:46 +0000</pubDate><description>&lt;p&gt;For those of you that have been at PowerShell Summits over the last few years you’ll have heard Jeffrey Snover state that he wanted to take PowerShell to other platforms.&lt;/p&gt;
&lt;p&gt;Now its happened&lt;/p&gt;
&lt;p&gt;Jeffrey has announced that an ALPHA release of PowerShell is now available for Linux and Mac.  Currently available for Ubuntu, Centos, Red Hat and Mac OS X with more to come&lt;/p&gt;
&lt;p&gt;The announcement is at&lt;/p&gt;
&lt;p&gt;&lt;a href="https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/"&gt;https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;Also see PowerShell blog&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>For those of you that have been at PowerShell Summits over the last few years you’ll have heard Jeffrey Snover state that he wanted to take PowerShell to other platforms.</p><p>Now its happened</p><p>Jeffrey has announced that an ALPHA release of PowerShell is now available for Linux and Mac.  Currently available for Ubuntu, Centos, Red Hat and Mac OS X with more to come</p><p>The announcement is at</p><p><a href="https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/">https://azure.microsoft.com/en-us/blog/powershell-is-open-sourced-and-is-available-on-linux/</a></p><p>Also see PowerShell blog</p><p><a href="https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/">https://blogs.msdn.microsoft.com/powershell/2016/08/18/powershell-on-linux-and-open-source-2/</a></p><p>Some  points to note:</p><p>ISE isn’t available as part of the alphas release but VSCode is available for Linux and Mac giving an consistent editor across the platforms</p><p>PowerShell remoting will be extended to use Open SSH as well as WSMAN</p><p>Planned enhancements include:</p><p>Additional Linux Distros covered – parity with .NET Core.</p><p>Writing Cmdlets in Python and other languages</p><p>PSRP over OpenSSH</p><p>WSMan based remoting to downlevel versions of Windows and WSMan based PSRP on Linux.</p><p>Editor Services and auto-generated GUI</p><p>Unix-style wildcard expansion</p><p>Increasing test code coverage for Windows and Linux editions</p><p>Continue increasing cmdlet coverage for Linux and Windows</p><p>REMEMBER this an ALPHA release – there’s still a lot to do and its a open source project so community effort is required</p><p>Enjoy</p>
]]></content:encoded></item><item><title>A date with PowerShell</title><link>https://powershell.org/articles/2016-08-11-a-date-with-powershell/</link><guid>https://powershell.org/articles/2016-08-11-a-date-with-powershell/</guid><pubDate>Thu, 11 Aug 2016 20:42:40 +0000</pubDate><description>&lt;p&gt;At the beginning of July, we welcomed our 3rd son into the world. As days past my wife and I would say, &amp;ldquo;wow, he&amp;rsquo;s 11 days old. Can you believe it?!&amp;rdquo;. I&amp;rsquo;m sure parents out there are relating to this!&lt;br&gt;
This gave me an idea for a fun script that would get your age in years, months and days, tell you how many days until your birthday and your star sign.&lt;br&gt;
I wanted date of birth passed to the function as &amp;lsquo;dd/MM/yy&amp;rsquo;. To keep to this format, I’m using the &amp;lsquo;ValidatePattern&amp;rsquo; Advanced Parameter with a Regular Expression (Regex). The regular expression, &amp;ldquo;^(0[1-9]|[12]\d|3[01])/(0[1-9]|1[0-2])/(\d{2})$&amp;rdquo;, will only allow a date in the format of 01/01/16, for example.&lt;br&gt;
Briefly, here is regex syntax I used in some of the expression:&lt;br&gt;
^ Start of string&lt;br&gt;
( .. ) Capturing group&lt;br&gt;
(0[1-9] Match two digits that make up the day. This accepts numbers from 01 to 09&lt;br&gt;
| Acts like a Boolean OR.&lt;br&gt;
/d match any digital character&lt;br&gt;
[12] match any character in the set&lt;br&gt;
/ used to divide the date numbers&lt;br&gt;
{2} Exactly two times&lt;br&gt;
$ End of string&lt;br&gt;
Now that my function parameter variable $Bday has a date, its passed to get-date to be converted from a string to a date. The date in variable $cDate will look like this, &amp;lsquo;01 January 2016 00:00:00&amp;rsquo;. The next line in the code will use todays date and subtract the date passed in $cDate variable. The $diff variable will contain the following data which we will use to get our age in years, months and days:&lt;br&gt;
Days : 212&lt;br&gt;
Hours : 12&lt;br&gt;
Minutes : 40&lt;br&gt;
Seconds : 20&lt;br&gt;
Milliseconds : 533&lt;br&gt;
Ticks : 183624205335135&lt;br&gt;
TotalDays : 212.528015434184&lt;br&gt;
TotalHours : 5100.67237042042&lt;br&gt;
TotalMinutes : 306040.342225225&lt;br&gt;
TotalSeconds : 18362420.5335135&lt;br&gt;
TotalMilliseconds : 18362420533.5135&lt;br&gt;
I&amp;rsquo;ve contained this first part in our Begin block. The Process block does the main code.&lt;br&gt;
Now I need to get my age in Years, Months and Days. This is where the [math] data type is used. I&amp;rsquo;m using the &amp;lsquo;Truncate&amp;rsquo; property as I don&amp;rsquo;t want to do anything fancy like round up my numbers. Adding the .typename of Days to my $diff variable and dividing by $daysInYear variable I can get my age in years.&lt;br&gt;
The next two, months and days required a tweak to the algorithm.&lt;br&gt;
I ended up using a maths term called a &amp;lsquo;Mod&amp;rsquo;. Now I’m not talking about youth culture and style in the sixties (Mods and rockers anyone ??), but the Modulus Math Operator. Basically the Modulus Operator returns the remainder when the first number is divided by the second. So for example:&lt;br&gt;
1 mod 3 = 1 (or 1 % 3 = 1)&lt;br&gt;
2 mod 3 = 2&lt;br&gt;
3 mod 3 = 0&lt;br&gt;
4 mod 3 = 1&lt;br&gt;
The operator sign used is % for Modulus. Not to be confused for the alias of foreach in PowerShell. For days in a month, I used the average of 30.&lt;br&gt;
I thought it would be fun to add the star sign as well. I was after something that could tell me, &amp;ldquo;is this date in this date range?&amp;rdquo;. One of the properties of &amp;lsquo;get-date&amp;rsquo; is DayOfYear.&lt;br&gt;
Finding if a number is in a range is pretty straight forward, For example:&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>At the beginning of July, we welcomed our 3rd son into the world. As days past my wife and I would say, &ldquo;wow, he&rsquo;s 11 days old. Can you believe it?!&rdquo;. I&rsquo;m sure parents out there are relating to this!<br>
This gave me an idea for a fun script that would get your age in years, months and days, tell you how many days until your birthday and your star sign.<br>
I wanted date of birth passed to the function as &lsquo;dd/MM/yy&rsquo;. To keep to this format, I’m using the &lsquo;ValidatePattern&rsquo; Advanced Parameter with a Regular Expression (Regex). The regular expression, &ldquo;^(0[1-9]|[12]\d|3[01])/(0[1-9]|1[0-2])/(\d{2})$&rdquo;, will only allow a date in the format of 01/01/16, for example.<br>
Briefly, here is regex syntax I used in some of the expression:<br>
^ Start of string<br>
( .. ) Capturing group<br>
(0[1-9] Match two digits that make up the day. This accepts numbers from 01 to 09<br>
| Acts like a Boolean OR.<br>
/d match any digital character<br>
[12] match any character in the set<br>
/ used to divide the date numbers<br>
{2} Exactly two times<br>
$ End of string<br>
Now that my function parameter variable $Bday has a date, its passed to get-date to be converted from a string to a date. The date in variable $cDate will look like this, &lsquo;01 January 2016 00:00:00&rsquo;. The next line in the code will use todays date and subtract the date passed in $cDate variable. The $diff variable will contain the following data which we will use to get our age in years, months and days:<br>
Days : 212<br>
Hours : 12<br>
Minutes : 40<br>
Seconds : 20<br>
Milliseconds : 533<br>
Ticks : 183624205335135<br>
TotalDays : 212.528015434184<br>
TotalHours : 5100.67237042042<br>
TotalMinutes : 306040.342225225<br>
TotalSeconds : 18362420.5335135<br>
TotalMilliseconds : 18362420533.5135<br>
I&rsquo;ve contained this first part in our Begin block. The Process block does the main code.<br>
Now I need to get my age in Years, Months and Days. This is where the [math] data type is used. I&rsquo;m using the &lsquo;Truncate&rsquo; property as I don&rsquo;t want to do anything fancy like round up my numbers. Adding the .typename of Days to my $diff variable and dividing by $daysInYear variable I can get my age in years.<br>
The next two, months and days required a tweak to the algorithm.<br>
I ended up using a maths term called a &lsquo;Mod&rsquo;. Now I’m not talking about youth culture and style in the sixties (Mods and rockers anyone ??), but the Modulus Math Operator. Basically the Modulus Operator returns the remainder when the first number is divided by the second. So for example:<br>
1 mod 3 = 1 (or 1 % 3 = 1)<br>
2 mod 3 = 2<br>
3 mod 3 = 0<br>
4 mod 3 = 1<br>
The operator sign used is % for Modulus. Not to be confused for the alias of foreach in PowerShell. For days in a month, I used the average of 30.<br>
I thought it would be fun to add the star sign as well. I was after something that could tell me, &ldquo;is this date in this date range?&rdquo;. One of the properties of &lsquo;get-date&rsquo; is DayOfYear.<br>
Finding if a number is in a range is pretty straight forward, For example:</p><p><code>5 -in 1..10</code>Which gives a Boolean result.<br>
Now if I convert my date ranges into days of the year then I can match the day of the year I was born against the ranges of days for star signs. I&rsquo;ve used a switch statement to check against multiple conditions. Within a scriptblock I’ve asked if the value I’m passing is &lsquo;in&rsquo; the array of dates for each star sign. The match will return the star sign and is held in the $starSign variable.<br>
The Final part of the process block is to work out how many days until your next birthday. By capturing the current date, formatting the date of birth by removing the year born, adding the current year and finally subtract the amended date of birth against the current date. Phew!<br>
This will leave a number of days until your next birthday. The &lsquo;if&rsquo; statement is added if your birthday has already happened at the time of the code, it simply reverses the sum to give a positive number.<br>
The end block displays the three captured results to the host.<br>
I hope you have enjoyed this post and can see the many options possible for dates in PowerShell.<br>
Feel free to download the script from my GitHub<a href="https://github.com/Gbeer7/Get-Age.git">https://github.com/Gbeer7/Get-Age.git</a></p><p><code>function Get-age { param( [Parameter(Mandatory=$true, HelpMessage="Date must be written as dd/mm/yy", Position=0)] [ValidatePattern("^(0[1-9]|[12]\d|3[01])/(0[1-9]|1[0-2])/(\d{2})$")] [string]$Bday ) Begin { # use 'get-date' to convert '$Bday' Variable $cDate = (get-date -Date $Bday) # from today's date subtract birth date $diff = (Get-Date).Subtract($cDate) } Process { # Work out Years, months and days [int]$daysInYear = '365' [int]$averageMonth = '30' # years $totalYears = [math]::Truncate( $($diff.Days) / $daysInYear ) $totalMonths = [math]::Truncate( $($diff.Days) % $daysInYear / $averageMonth ) # days $remainingDays = [math]::Truncate( $($diff.Days) % $daysInYear % $averageMonth ) # Your star sign $thisYear = (get-date).Year $starSign = switch ($cDate.DayOfYear) { { $_ -in @( ((get-date 22/12/$thisYear).DayOfYear)..365; 0..((get-date 19/01/$thisYear).DayOfYear) ) } { "Capricorn" } { $_ -in @( ((get-date 20/01/$thisYear).DayOfYear)..((get-date 18/02/$thisYear).DayOfYear) ) } { "Aquarius" } { $_ -in @( ((get-date 19/02/$thisYear).DayOfYear)..((get-date 20/03/$thisYear).DayOfYear) ) } { "Pisces" } { $_ -in @( ((get-date 21/03/$thisYear).DayOfYear)..((get-date 19/04/$thisYear).DayOfYear) ) } { "Aries" } { $_ -in @( ((get-date 20/04/$thisYear).DayOfYear)..((get-date 20/05/$thisYear).DayOfYear) ) } { "Taurus" } { $_ -in @( ((get-date 21/05/$thisYear).DayOfYear)..((get-date 20/06/$thisYear).DayOfYear) ) } { "Gemini" } { $_ -in @( ((get-date 21/06/$thisYear).DayOfYear)..((get-date 22/07/$thisYear).DayOfYear) ) } { "Cancer" } { $_ -in @( ((get-date 23/07/$thisYear).DayOfYear)..((get-date 22/08/$thisYear).DayOfYear) ) } { "Leo" } { $_ -in @( ((get-date 23/08/$thisYear).DayOfYear)..((get-date 22/09/$thisYear).DayOfYear) ) } { "Virgo" } { $_ -in @( ((get-date 23/09/$thisYear).DayOfYear)..((get-date 22/10/$thisYear).DayOfYear) ) } { "Libra" } { $_ -in @( ((get-date 23/10/$thisYear).DayOfYear)..((get-date 21/11/$thisYear).DayOfYear) ) } { "Scorpio" } { $_ -in @( ((get-date 22/10/$thisYear).DayOfYear)..((get-date 21/12/$thisYear).DayOfYear) ) } { "Sagittarius" } } # Work out how many days until birthday $now = [DateTime]::Now $dm = get-date $Bday -UFormat "%m/%d/" $Days = [Datetime]($dm + $now.Year) – $Now # If birthday has happened this year change sum if (!($Days -ge 0)) { $Days = $now - [Datetime]($dm + $now.Year) } } End { # display "</code>nYou are {0} year(s), {1} month(s) and {2} day(s)" -f $totalYears, $totalMonths, $remainingDays
&ldquo;Your Star sign is: " + $starSign
# and&hellip;
if ($cDate.Year -eq (get-date).Year) {
&ldquo;You have another $($daysInYear - $diff.Days) days until your birthday&rdquo; # If you are under 1 years old
} else {
&ldquo;You have another $($Days.days) days until your birthday&rdquo; # over the age of 1
}
}
}# Function End
`</p>
]]></content:encoded></item><item><title>What are your "known problems" (solved) in DSC?</title><link>https://powershell.org/articles/2016-08-08-what-are-your-known-problems-solved-in-dsc/</link><guid>https://powershell.org/articles/2016-08-08-what-are-your-known-problems-solved-in-dsc/</guid><pubDate>Mon, 08 Aug 2016 19:32:02 +0000</pubDate><description>&lt;p&gt;I&amp;rsquo;m collecting a list of known problems in DSC v5 _that have been solved. _Like the infamous &amp;ldquo;MI RESULT 12&amp;rdquo; error that could happen if you upgraded from prerelease v5 to production preview. I&amp;rsquo;m going to document these in &amp;ldquo;The DSC Book,&amp;rdquo; including in its free sample version, to help preserve these things in one place.&lt;br&gt;
Again - these need to be &lt;em&gt;solved&lt;/em&gt; problems. Just drop as much description as you can into a comment here, and feel free to link to the fix, or to a discussion thread on the problem.&lt;br&gt;
And please - pass this around. If you&amp;rsquo;ve never had a chance to contribute to &amp;ldquo;the community&amp;rdquo; before, now&amp;rsquo;s a great time. Even if it&amp;rsquo;s a problem that you know doesn&amp;rsquo;t exist in the &lt;em&gt;current&lt;/em&gt; v5 release, let&amp;rsquo;s please just document its former existence.&lt;br&gt;
Thanks!&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>I&rsquo;m collecting a list of known problems in DSC v5 _that have been solved. _Like the infamous &ldquo;MI RESULT 12&rdquo; error that could happen if you upgraded from prerelease v5 to production preview. I&rsquo;m going to document these in &ldquo;The DSC Book,&rdquo; including in its free sample version, to help preserve these things in one place.<br>
Again - these need to be <em>solved</em> problems. Just drop as much description as you can into a comment here, and feel free to link to the fix, or to a discussion thread on the problem.<br>
And please - pass this around. If you&rsquo;ve never had a chance to contribute to &ldquo;the community&rdquo; before, now&rsquo;s a great time. Even if it&rsquo;s a problem that you know doesn&rsquo;t exist in the <em>current</em> v5 release, let&rsquo;s please just document its former existence.<br>
Thanks!</p>
]]></content:encoded></item><item><title>PowerShell and DevOps Global Summit 2017: Call for Topics</title><link>https://powershell.org/articles/2016-08-01-powershell-and-devops-global-summit-2017-call-for-topics/</link><guid>https://powershell.org/articles/2016-08-01-powershell-and-devops-global-summit-2017-call-for-topics/</guid><pubDate>Mon, 01 Aug 2016 11:09:22 +0000</pubDate><description>&lt;p&gt;The PowerShell and DevOps Global Summit is the number one conference where PowerShell enthusiasts gather and learn from each other in fast-paced, knowledge packed presentations. PowerShell, and DevOps, experts from all over the world including MVP’s, community leaders and PowerShell team members, will once again join together for a few days in Bellevue, WA. to discuss and learn about maximizing PowerShell in the workplace.&lt;/p&gt;
&lt;p&gt;It&amp;rsquo;s also the place to explore and further your knowledge of DevOps principles and practices in a Windows environment. It&amp;rsquo;s a place to make new connections, learn new techniques, and offer something to your peers and colleagues. If you want to share your PowerShell or DevOps expertise, then this is your official call to submit presentations for selection!&lt;/p&gt;</description><content:encoded>&lt;![CDATA[<p>The PowerShell and DevOps Global Summit is the number one conference where PowerShell enthusiasts gather and learn from each other in fast-paced, knowledge packed presentations. PowerShell, and DevOps, experts from all over the world including MVP’s, community leaders and PowerShell team members, will once again join together for a few days in Bellevue, WA. to discuss and learn about maximizing PowerShell in the workplace.</p><p>It&rsquo;s also the place to explore and further your knowledge of DevOps principles and practices in a Windows environment. It&rsquo;s a place to make new connections, learn new techniques, and offer something to your peers and colleagues. If you want to share your PowerShell or DevOps expertise, then this is your official call to submit presentations for selection!</p><p>The PowerShell and DevOps Global Summit 2017 will be returning to the Meydenbauer center, Bellevue WA on 9-12 April 2017.</p><h2 id="topic-areas-what-we-are-looking-for" class="ps-heading"><strong>TOPIC AREAS– What we are looking for</strong><a class="ps-heading-anchor" href="#topic-areas-what-we-are-looking-for" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>We are looking for presentations in a number of areas. The bulk of our sessions follow our now traditional 45-minute format. These sessions cover a wide aspect of PowerShell and DevOps expertise. Your proposed session should fit into one of the following areas:</p><ul><li>PowerShell Internals – A deep look into the inside workings of PowerShell and practical solutions that are built from them. These presentations are typically more directed to the PowerShell development community that is building extensions and solutions relating to PowerShell.</li><li>PowerShell Features Deep Dive – These presentations are a deep look into configuring and working with PowerShell features and capabilities such as Remoting, Desired State Configuration and more. These presentations tend to be more IT Pro focused.</li><li>DevOps in Practice – A deep dive into putting the DevOps principles into practice. PowerShell may be a part of DevOps in your organization or you may be using other tools. Presentations should focus on what you’re doing and how you’re doing it.</li></ul><p>We are open to presentations across the entire ecosystem that has been built around PowerShell or the various DevOps tools. Don’t hesitate to send an abstract for your particular area of expertise. This includes Microsoft platforms and products that have PowerShell-based management tools as well as third party products.</p><p>New topics will be preferred over the recycling of older topics – look to see what’s new in PowerShell 5.0 and use the questions on PowerShell.org to spot areas that could supply a good session for the Summit. However, we are still open to sessions on ‘older’ topics that address areas of great confusion or uncertainty.</p><p>We have a very limited number agenda slots available for double length sessions. These are reserved for experienced speakers that are delving into depths of a topic. Recent Summit’s have had sessions on security, containers on Windows, Azure automation and PowerShell based screen scraping. Please contact us –<a href="mailto:summit@powershell.org">summit@powershell.org</a> – with your idea before spending too much time developing such a session.</p><p>On Sunday 9 April we will have six 3 hour sessions available. These should cover either foundational topics that will either bring attendees up to speed in a particular area or be a very deep dive into an advanced topic. Again, these are reserved for experienced speakers so please contact us –<a href="mailto:summit@powershell.org">summit@powershell.org</a> – with your idea before spending too much time developing such a session.</p><p>Also on Sunday we’re looking to present half day workshops – Function review and DSC Resource review. Bring your code and get expert analysis and feedback together with help solving your problems in these areas. We’re looking for PowerShell and DSC experts to run these sessions. Please contact us –<a href="mailto:summit@powershell.org">summit@powershell.org</a> – if you could run such a session.</p><h2 id="what-kind-of-sessions-get-selected" class="ps-heading">** What kind of sessions get selected?**<a class="ps-heading-anchor" href="#what-kind-of-sessions-get-selected" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>We’re looking for sessions that go beyond – way beyond – ‘beginner’.  This is an ‘experts’ level conference and we expect the session to reflect that.<br>
If you want to see examples of the depth we’re looking for use the recordings on the PowerShell.org Youtube channel from last year’s PowerShell and DevOps Global Summit as a guide.</p><p>We look for an abstract that’s compelling and makes us want to see your session – so spend time writing a punchy abstract! We want sessions that offer real-world usability combined with ‘WOW, nobody talks about THAT’ awesomeness.</p><p>We want to see the code. Don’t just talk about it – this is a PowerShell summit not a PowerPoint Summit. If your session isn’t predominately demonstrations its probably not right for the Summit.</p><p>Summit presentations are intense and intimate often with plenty of audience interaction. You must expect questions and discussions. This is not a “lecture to the audience” event. Also because of the session length, generally co-presenters are unnecessary, but that is not a requirement.
AIM HIGH, VERY HIGH.</p><p>Remember, Summit sessions are recorded, so if you’ve previously presented a topic at a Summit, we’re less likely to choose it for another Summit.</p><p>We want sessions that are challenging, and that ideally present things that simply aren’t explained or documented elsewhere. New modules, new techniques, and crazy approaches are all welcome. Discussion-format sessions are great, too, especially if you plan to turn them into a community deliverable (like a “best practices for writing DSC Resources” session that gets turned into a free e-guide later). Think community, deep dive, engaging, and amazing as keywords. We want attendees to finish each day with information leaking… just a little bit… out their eyeballs. Help us make it happen.</p><p>If you are going to be presenting about a module you’ve created don’t just show it in use. Show the code! Show how you solved the problem! What issues did you have and how did you do to overcome them?</p><p>You are more likely to be accepted as a speaker if you have multiple sessions we can accept. We have a very limited speaker budget and to maximize value to attendees we need to keep our costs down. We can do this if speakers present multiple sessions. They don’t have to be on the same topic – its better if they aren’t.</p><p>To give you some ideas we’ve conducted a survey of topics potential attendees would like to see covered:</p><ul><li>DevOps tools and practices</li><li>DevOps on Windows</li><li>Source control</li><li>Testing – pester, OVF, TDD etc.</li><li>Metrics and measurements in DevOps</li><li>PowerShell next generation</li><li>JEA</li><li>Exchange web services</li><li>System Center – SCSM, SCCM</li><li>PowerShell + SQL Server</li><li>Software Inventory logging</li><li>More DSC – specially to enable WinOps</li></ul><p>If you have any doubts about the suitability of a particular session, please contact us -<a href="mailto:summit@powershell.org">summit@powershell.org</a> – we’re always happy to discuss proposed sessions.</p><p>We do have some goals for speaker selection, too. We obviously have, and appreciate, the great involvement we get from the product team. We aim to have a certain number of sessions from well-known members of the community, simply because they’re well-known for a reason – they do a great job! But we also set aside slots for newcomers who’ve never presented before, or who’ve maybe only presented once or twice before – the audience will judge you on content not style. We want to create opportunities for more folks to become engaged and active in our community, and the Summit is a great way to do that.</p><p>We aren’t looking for soft-skills sessions, like “how to get a new user group running,” although contact us via email (<a href="mailto:summit@powershell.org">summit@powershell.org</a>) if you’d like to do something like that as an extra evening thing after the main content wraps for the day.</p><p>Please note all sessions are to be delivered in English. Presenter will provide all equipment needed to deliver session(s), including a laptop or other computer. Presenter must be able to provide video by means of HDMI, DVI-D, or DisplayPort connectors – VGA is NOT supported. Presenter must be able to manually select an appropriate screen resolution for video output. Typically, 1024×768 or 1280×720 are preferred.</p><p>Internet connectivity is available in the conference center but bandwidth is limited. If you rely on connecting to the cloud for your sessions then consider recording any demonstrations as a contingency.</p><h2 id="how-to-submit-abstracts-of-presentations" class="ps-heading"><strong>How to submit abstracts of presentations</strong><a class="ps-heading-anchor" href="#how-to-submit-abstracts-of-presentations" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Presentations will be 45-minutes in length and the submission should include the following:</p><ul><li>Presentation Title</li><li>Presentation abstract – a description of the presentation and the topics covered. 250 words or less and suitable for marketing.</li></ul><p>Go to<a href="https://www.eventloom.com/event/register/summit2017/Speaker?preregister=1">https://www.eventloom.com/event/register/summit2017/Speaker?preregister=1</a>. Notice that you&rsquo;ll get a certificate error if you don&rsquo;t use the &ldquo;www&rdquo; at the front.</p><p>This is the only valid URL for pre-registration. Provide and confirm your e-mail address, name and other required details. You’re creating a new account, even if you’ve attended past Summit events.</p><p><strong>DO NOT ATTEMPT TO REGISTER FOR THE SUMMIT AS AN ATTENDEE AT THIS STAGE – WE WILL BE OPENING REGISTRATION IN NOVEMBER 2016. ANY NON-SPEAKER REGISTRATIONS WILL BE DELETED AT THAT TIME.</strong></p><ul><li>Click Abstracts on the top menu</li><li>Click SUBMIT ABSTRACT</li><li>Enter Title and Description.</li><li>Click SUBMIT</li><li>Provide a title and description; descriptions must be 50-250 words. Set the Status to “Ready to Review” when you are ready to send your session to us for consideration.</li></ul><p>To return to the site at a later time, go to<a href="https://www.eventloom.com/event/login/summit2017">https://www.eventloom.com/event/login/summit2017</a>
Click Log In. You can then re-visit Abstracts.</p><p>Note that you must set your abstract status to Ready for Review or we won’t see it. If you leave it in Pending, it won’t be considered.</p><p>You can submit multiple presentations in the same topic area or for different ones. Be aware that even though the session length is 45 minutes we prefer to have at least 10 minutes set aside for questions.</p><h2 id="presentation-submission-deadline--when-you-should-send-it-by" class="ps-heading"><strong>Presentation submission deadline – When you should send it by</strong><a class="ps-heading-anchor" href="#presentation-submission-deadline--when-you-should-send-it-by" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>Start sending your presentation submissions immediately! The selection committee will start selecting presentations as soon as they arrive so you don’t want to miss out. The last day we will accept presentation submissions will be Sunday 2 October 2016. This is a hard deadline – NO sessions will be accepted after this date.</p><h2 id="when-you-will-know-youve-been-selected" class="ps-heading"><strong>When you will know you’ve been selected</strong><a class="ps-heading-anchor" href="#when-you-will-know-youve-been-selected" aria-label="Link to this section" title="Link to this section"><i class="fas fa-link" aria-hidden="true"/></a></h2><p>The selection committee will start reviewing submissions immediately and begin the selection process. You will be informed if one or more of your presentations have been selected and notified by Monday 10 October 2016.</p><p>You will need to log back onto the event site and complete your registration with the code we will provide in the notification email. This will have to occur before 23 October 2016 so that we have a completed agenda in time for attendee registration.</p><p>We will notify all potential speakers by 23 October 2016 if their sessions haven’t been accepted.</p><p>Speakers, with accepted sessions, will be given free admission to the event, including attendance at all official Summit activities. Speakers may not bring guests to the day sessions or evening events. We have a limited budget, and the number of speakers selected will be governed by that budget.</p><p>All speakers will receive a stipend of $400 per session (more for the longer Sunday sessions) to assist with travelling and accommodation expenses.</p><p>Pre-registering as a speaker does not guarantee you a place at the event. If any sessions are accepted, you will be asked to immediately complete your Summit registration using a free promotional code. If you do not complete your registration by 23 October 2016, then we will assume you do not wish to present and your sessions will be cancelled, and the slots offered to another speaker.</p><p>If no sessions are accepted, then your pre-registration will be deleted. Beginning 1 November 2016 and through 3 March 2017, you are welcome to create a new account and register as a standard attendee on a space-available basis.</p><p>The final agenda will be announced and posted on PowerShell.Org on, or about, Tuesday 1 November 2016.</p><p>We look forward to your submissions and your help in making PowerShell and DevOps Global Summit 2017 the most valuable IT/Dev conference of the year building on and surpassing the previous Summits!</p>
]]></content:encoded></item></channel></rss>