We’re often asked if we’re planning to have a PowerShell Summit in (insert name of town/country/city). The answer is, “no,” because we’re usually not planning much in advance of whatever’s currently on the table. Keep in mind - **we’re all volunteers. **We don’t have a ton of free time to plan 3 years out! As you’ll see in a minute, it’s a lot of work. That said, you can play a big role in bringing the Summit to your town. How? Simply write a proposal and submit it to us. Use the “Admin” e-mail alias at PowerShell.org. Here’s what to include:
As we move into the middle of PowerShell Summit Europe 2014, we have a lot of folks asking, “when will you hold a Summit in ____” (insert the name of your favorite country). Right now, PowerShell.org is committed to organizing both North American and European events, one per year, while there is audience demand for them. Both events will shift locations from year to year, and the location choice is driven by a number of criteria - mainly financial ones. But we’re all volunteers here. Each event requires upwards of 240 man-hours to put together, and an up-front financial commitment of up to $25,000. We’re getting to the point where the organization can front that money, but it’s been on personal credit cards to this point, paid back only once the event is complete. So… it’s a big deal. Strictly from a time perspective, we just don’t have enough to organize more events elsewhere in the world. However, we continue to encourage folks to organize their own events. We’ve even come up with a brand name to get you started: PowerShell Forum. The idea is for those to be smaller 2-3 day, regional-level events that we help promote. We’ll provide all the advice we can to help get you going, too. We’ll put you in touch with the right folks so that if product team participation is an option, you can find out. We hope that a PowerShell Forum “grows up” to one day host a PowerShell Summit - because the organizers and volunteers are in place to let us hold a full Summit without taking on the entire time commitment ourselves. In any community, if you want something good to come your way, the best way is to do it yourself - rather than asking someone else to bring the good to you. We feel that’s particularly true with live events, because you know the local market, the venues, the audience, the customs, the laws, and so on. So, “when will there be a PowerShell Summit in _____?” The answer is, “when you make it happen.” We’d love to help - but you’ll have to take the first step.
On Monday night (Amsterdam time, September 29th), we’ll be holding the first DSC Hackathon at PowerShell Summit Europe 2014. Attached are the scenarios we’ll be asking participants to select from. We’ll ask everyone to work in small groups, pick one scenario, and try to produce a custom DSC resource that solves the problem. Many of these are from Microsoft’s own internal “wish list” of resources that they don’t yet have anyone assigned to. You’re welcome to participate, even if you’re not present at the Summit. You _will _need to operate in Amsterdam time; we’re only accepting submissions during that time (from about 6pm local time). If you’d like to participate, you’ll need a Twitter account to begin with. When the Hackathon starts, drop a tweet that includes the hash tag #DSCHackathon, as well as the scenario you’d like to work on. We’ll respond and connect you with a group that’s working on that scenario. From there, the group will let you know how they’d like to communicate - possibly a Skype chat window, possibly an IRC chat, it’ll be up to them. In the event that Internet connectivity sucks, we’ll simply do our best, and may direct remote users to work on their own. But, if you monitor the #DSCHackathon tag, you may be able to find other remote users to team up with. There are no prizes - we’re doing this for the good of the community. However, every team who hands in a working resource will get public recognition in the PowerShell team blog, on PowerShell.org, and wherever else we can manage to mention you :). As a reminder, you should plan to have Windows PowerShell v4 or later on your laptop in order to participate. We don’t anticipate going longer than 2-3 hours, and if you’re on-site plan to use battery power for the entire period. Ideally, you’ll want a server VM or two so that you can test the scenarios… which are attached herewith. And it’s fine to get an early start on these, if you like. Download: DSC Hackathon Scenarios
If you’re planning to attend PowerShell Summit North America 2015, to be held at the end of April 2015 in Charlotte, North Carolina, you should read the following important information:
The registration site will be open from 30 October 2014 to 30 March 2015. There is about a 30-day window from the end of registration to the event itself. There are no exceptions to this cutoff.
You should read the extremely important information about registering. It also contains links to the agenda and to the registration site.
The agenda will be available in mid-October 2014.
We will only have about 90 seats available due to the size of the venue. You will probably need to plan to register early, because we don’t have a magical way of making the building bigger to accommodate “just one more person.”
We will not be holding seats for later registrations. Everything becomes available on 30 October 2014. We’ve done the “phased release” before and it was a major PITA.
Yes, we will be recording all sessions and posting them on the PowerShell.org YouTube channel. We will not be live-streaming because the facilities don’t exist to do so. Recordings will include slides/demos and a room microphone; this will not be Channel 9-quality, but it should get the job done. Or you could, you know, show up at the live event.
If you are planning to have someone in your organization register and pay on your behalf, it is crucial that they do so
using your e-mail address
, not theirs. Otherwise, we may not be able to admit you to the event. **
This is a big deal.
**Please don’t mess it up. **
Please help us get the word out.
** This is entirely a community event, run entirely by volunteers who are paying their own way to the event also. We have zero marketing and advertising budget, because we try to keep the overall costs as low as humanly possible. Set reminders to tweet, Facebook, etc. once a month and help us let the world know about the event.
Aside from classes and new DSC features, which I’ve already written about, there are a number of less-headline, but still-very-awesome, new capabilities. This article is based on the September 2014 preview release of WMF 5.0. Information is highly subject to change. First up is the **ability to automatically create PowerShell cmdlets from an OData endpoint. **Huh? OData is a kind of web service (basically); PowerShell gains the ability to look at the endpoint and construct a set of proxy cmdlets that let you interact with the endpoint more naturally. This is spiritually similar to what PowerShell can already do for a SOAP web service endpoint. Next are some 7-years-overdue cmdlets for managing ZIP files: Compress-Archive and Expand-Archive. Finally. These use underlying .NET Framework ZIP functionality (I think), which has had some compatibility problems in the past, so we’ll see how these hold up. But they should be the missing link to letting you do everything DSC-related right in PowerShell, since you can now ZIP up your custom resources for deployment via pull server. Auditing gets a huge win, and this is really more of a headline feature than people think. For one, the ISE now supports transcript creation. Yay! You can also “nest” transcripts, meaning you can have one running, and then start a second one to cover only a portion of time. Closing the second one lets the first remain running. You can also specify a central transcript directory, which is useful when you want to collect these things into a central folder for reporting. For example, you should now be able to set up Remoting endpoints that automatically kick off a transcript when someone connects, and saves them to that central location. More auditing comes in the form of Group Policy settings. You’ve always been able to log the fact that certain commands were run (did you know that?), but now you can enable detailed script tracing that logs a crapload of detail to the PowerShell operational log (which can, like any other event log, be forwarded to another server). You get the complete details of every script block executed, even if it creates another script block. Again, this is set up in Group Policy - check out the WMF 5.0 release notes for the location. Ed Snowden gets a face slap with new Cryptographic Message Syntax (CMS) cmdlets, including Get-CmsMessage, Protect-CmsMessage, and Unprotect-CmsMessage. These use PKI to encrypt data. By the way, **if your organization doesn’t already have an internal PKI, WTF are you waiting for, you’re ten years behind the curve, man. **PKI becomes more important to Windows environments every single day, and you need to get with the program. There’s also a new **fun feature for extracting content from strings. This system uses some Microsoft Research functionality called FlashExtract. Essentially, you give it examples of what your data looks like, and then point it to a big string (like a text file) full of data. It can extract all the data pieces based on your example. It’s early days for this technology, but it’s kind of awesome to see the PowerShell team giving us an easy way to play with it. Because WMF 5.0 introduces PowerShellGet, **it now includes commands to add PowerShellGet repositories. That means you can stand up your own repo, host your modules there, and install modules by simply running Install-Module (or find them using Find-Module). Tres awesome! We don’t yet have technical details on what the heck a PowerShellGet repository actually looks like, but I’m sure that’ll crop up. ARE YOU PLAYING WITH WMF 5.0 ON A NON-PRODUCTION VM YET? YOU SHOULD BE. Times are changing and you gotta keep up!
When Desired State Configuration (DSC) came out - gosh, just about a year ago - I kept telling people that there was more to come. And a lot of it is now just around the corner in PowerShell v5. This article is written to the September 2014 preview release - things may change for the final release. A major set of changes in DSC is a much more detailed and granular configuration of the Local Configuration Manager (LCM), the local “agent” that makes DSC work on the target node. This new level of configuration really shows you where Microsoft’s thinking is. For example, a single target node can be configured _to pull configurations from multiple pull servers. _That doesn’t necessarily mean separate _machines, _as a single IIS instance can host multiple websites, but it means you’re no longer limited to one MOF per computer. Yes, I said that. The LCM can now pull (but not have pushed to it) _partial configurations. _Each partial configuration is a MOF, but the understanding is that there can be more than one. There’s still no dynamic evaluation of which MOFs will be pulled; you have to specify them all in the LCM configuration, but now you can break a machine’s total configuration into multiple bits. Each partial configuration is given a source, which is a pull server. Each partial configuration can be given exclusivity over certain resources. This helps avoid overlap. For example, you might decided that Partial Config A has exclusive control over all xIPAddress settings, meaning those settings from any other partial config wouldn’t work. Partial configurations can also depend on each other, so that (for example), Partial Config B won’t even run until Partial Config A is complete. The LCM can also have a separate server configured for web- or file-based resource repositories, meaning those can be separated from the pull server endpoint. What used to be called the “compliance server” is now simply the reporting server - we mentioned in “The DSC Book” that the name of this would likely change. It’s now a distinct configuration item, meaning even a node in Push mode can report its status to the reporting server! New global synchronization capabilities also exist. A node’s configuration can be made dependent on _a configuration item from another node. _Meaning, Node “A” won’t try to configure until Node “B” completes certain items first. Communications is all via WS-MAN and CIM. A new Get-DscConfigurationStatus returns a high-level status for a node - similar to what the reporting server would collect - and an amazing new Compare-DscConfiguration can now accept a configuration and tell you _where a given node differs. _This is a big deal, and something a lot of folks wanted in PowerShell v4. There’s also an **Update-DscConfiguration, **which forces a node to evaluate its DSC stuff right away. DSC is quickly coming of age. In less than a year, we’ve seen (so far) 6 releases of additional resources, and now with PowerShell v5 we’re seeing a number of important enhancements and evolutions in the core technology. Many of the things that frustrated folks initially are now taken care of.
This post is based on the September 2014 preview release of WMF 5.0. This is pre-release software, so this information may change. One of the banner new features in PowerShell v5 is support for real live .NET Framework class creation in Windows PowerShell. The WMF 5.0 download’s release notes has some good examples of what classes look like, but I wanted to briefly set some expectations for the feature, based on my own early experiences. The primary use case for classes, at this point, is for DSC resources. Rather than creating a special PowerShell module that has specially named functions, live in a specially named folder, and work in a special way - that’s a lot of special, which means a lot of room for error - classes provide a more declarative way of creating DSC resources. But we’re a bit ahead of ourselves. What’s a class? In object-oriented programming, a class is a hunk of code that provides a specific interface. Everything in the .NET Framework is a class. When you run Get-Process in PowerShell, for example, you are returning objects of the type System.Diagnostics.Process - or, in other languages, objects of the class System.Diagnostics.Process. Each process is an instance of the class. The class describes all the standardized things that a process can show you (like its name or ID), or that it can do (like terminate). Programmers build the functionality into the class itself. Classes can have static properties and methods - these are hunks of code that don’t require an actual instance of a process. For example, you can start a process without having a process in the first place. The System.Math class in .NET has lots of static members - the static property Pi, for example, contains the numeric value of pi to a certain number of decimal places. The static Abs() method returns the absolute value of a number. PowerShell classes are designed to provide similar functionality. The trick with PowerShell classes, at least at this stage of their development, is that they don’t add their type name to any kind of global namespace. That is, let’s say you write a class named My.Cool.Thing, and you save it into a script module named MyCoolThing.psm1. You can’t just go into the shell and run New-Object -TypeName My.Cool.Thing to create an instance of the class, because there’s nothing in PowerShell (yet) that knows to go look for your script module to find the class. That’ll likely change in a future release, but for right now it means classes are kind of limited. The basic rule is that you can only use a class _within the same module that contains the class. _That is, the class can only be “seen” from within the module. So, your MyCoolThing.psm1 module might define a class, and then might also define several commands (functions) that use the class - that’s legal, and it will work. You still can’t use New-Object; instead, you’d instantiate your class by using something like ClassName::new(), calling the static New() method of the class to instantiate it. I expect New-Object will get “hooked up” at some point, but it might not be until some future version of PowerShell. Anyway, back to DSC. DSC is a bit unique, because normally you don’t load resource modules; the Local Configuration Manager loads them. When you build a DSC resource class, you’re forced to provide three methods: Get(), Set(), and Test(). The LCM loads your module, instantiates the class, and then calls the three methods as needed. DSC resources built in this fashion can live in a plain old module .PSM1 file - there’s no need to create a DSCResources subfolder, no need to have an empty “root” module, or any of that. So it’s a more elegant solution all around. Aside from some structural differences, you code them the same as you always have. v5 still supports the old-style resources, for backward compatibility, but class-based resources are the “way forward.” I expect Microsoft will eventually refactor the DSC Resource Kit to be class-based resources, as soon as they get a minute and as soon as v5 is widely adopted. So most of the “wiring” behind classes has, to this point, been designed to support that DSC use case. In other words, of all the things a PowerShell class will need to do, the team has so far focused mainly on those things that impact DSC. The rest will come later - the release notes use the phrase, “…in this release” a lot, meaning the team understands where the current weaknesses are. “This release” in some cases may simply mean _this current preview release, _meaning they’re targeting more features for v5’s final release; in other cases, more features will have to wait for v6 (or whatever) or a later version of PowerShell. So there’s a little rambling on classes and what’s presently in PowerShell v5. If you haven’t already downloaded the preview and started playing with it, you should; _not in production, though. _Keep it in a test VM for the time being.
We’re hoping that everyone attending the PowerShell Summit Europe 2014 will join our Monday evening **DSC Hackathon, **where we’ll become “product team members for a night” and try to code up some DSC Resources from the team’s own internal wish list! We’ll provide a cash bar as well as finger food for our on-site attendees… but you’re welcome to participate remotely, too! Sometime on September 29th, watch PowerShell.org for a posting that includes the challenges. Choose your challenge, and follow the blog post instructions to submit them. We’ll also include details for participating live via IRC and other chat mechanisms, and we may be able to do a live room-cast via Lync or something. There are no winners and no losers - only the _entire community _wins, because completed entries will be added to the PowerShell.org GitHub repo and made available to the world, for free. But, coders who complete a resource will receive public recognition, both here on PowerShell.org and in some other very visible venues! Here’s what you’ll need to participate:
Did you know that PowerShell.org has, for more than a year now, offered a mostly-monthly TechLetter e-mail newsletter? It’s stuffed with community news, announcements (like our free webinar schedule), feature articles on PowerShell, and much more. It’s a great way to learn a little bit at a time, and it’s truly awesome content. And we keep back issues for your perusal! You can find the back issues online. We post all but the most recent 2-3 issues, but of course you can subscribe and have them delivered right to your inbox around the middle of most months. We’re always on the lookout for new content, too - and if you’re thinking, “oh, I have nothing really to share,” you’re wrong! It can be as simple as an article about something you figured out. With more than 5,000 subscribers, someone’s sure to appreciate your perspective! Contact our Editors at PowerShell.org via e-mail to submit your article, or to suggest an article idea. And please - tell a friend!
I know it’s been a “wish” of many folks for our forums to have better code formatting. Well, if you know some PHP and a little about WordPress, you can make it happen. What we need is a WordPress plugin that hooks the action for post displays. The plugin needs to take the post body, and look for anything contained within HTML “code” tags or “pre” tags. Within that content, the plugin needs to strip any further code/pre tags (WordPress has a bit of a glitch where it’ll sometimes nest them). It should then HTML-encode the remaining content to turn any backticks into an HTML entity. Finally, it should color-code the content, or whatever, and hand it back to WordPress for display. If you think you might be interested, let me know. There ARE existing code formatters. But they have some weaknesses:
