PowerShell.org is going to be launching TechSessions this Fall. These will be ~1 hour online webinars, which you’re welcome to attend live. We’ll also record them and make the recordings available. In most cases you will need to register for each one, so that we can send the appropriate invite information. Our sponsors are working with us on these, so each one might be in a different webinar platform (Lync, Webex, etc) depending on who is providing the infrastructure that month. In all cases, we’ll announce the TechSession in our TechLetter Newsletter, via banners on this site, and in a blog post. You’ll notice a new “TechSessions” post category for those announcements. I’ll be soliciting presenters, and the goal is just to provide you with varied technical content around PowerShell. If you’d like to BE a presenter, hit the Contact link in the Site Info menu (above) and let me know! Attending live will obviously give you a Q&A opportunity as well. Be on the lookout! I’m hoping to kick off in September or October. If there are specific topics you’d like to see, drop a comment below and let me know. I’m sure potential presenters would love some suggestions, and I know I would.
I have received a lot of interest in a PowerShell Summit Europe, and we are starting to look at doing one in 2014. I know that’s a long way off, but it takes time to put these together when everyone’s volunteering that time! I have put together a very short survey to see if there is any consensus on where such an event might be held. The survey is online now and ready for your opinions. Please forward this to your colleagues and co-workers, as well - we would really like a variety of opinions. If you want to tweet about it, Facebook it, or anything else to help us get a broad perspective, it would be much appreciated. I must note that this event will be in English, as it is meant to be a pan-European event that involves as many different folks as possible. We are not attempting to hold a more regional, culture-specific event - some of those already exist (I’m aware of one in Germany, for example), and they do a better job serving their local market (which can be quite large) than we could ever do. We are trying to fill a different need, which is more along the lines of a very miniature TechEd Europe, which brings as many different folks together as possible. Hopefully we will achieve that goal. Thank you for your time and input!
I’m informed that sometime today Microsoft will be posting fixed core cmdlet help files for your downloading pleasure - so it’s safe to run Update-Help again, and you should definitely do so. There are likely a lot of fixes and improvements to the help text, and you won’t be “losing” the parameter value type information from the SYNTAX section. Maybe schedule an Update-Help for tomorrow morning? BTW - kudos to the team at Microsoft for getting this issue fixed so quickly. It’s a shame this one snuck past them, but once notified of the problem they really did jump on it. The fact that the problem was (from the public perspective) just with the downloadable help files means it’s an easy fix that doesn’t involve pushing code out through Windows Update (thank goodness).
Through my company Concentrated Tech, I’ve decided to run a set of three PowerShell Summer School classes (click that link for descriptions). These will be a combo of self-study and weekly online sessions, designed to teach Toolmaking, Practical applications of PowerShell, or how to teach PowerShell in a lunch ’n’ learn style format. Registration is open from now until August 1st, and you’ll also get a discount on some great SAPIEN products to use during class, if you like. The Toolmaking class will also prepare you for PowerShell VERIFIED EFFECTIVEâ„¢ certification, if you’ve been considering that. Two of the classes will incorporate group code reviews of student assignments, to help improve your style; the third will include mock delivery sessions to help polish your delivery skills. All will include a private Q&A forum where you can ask questions both of me and of your fellow students while you’re in the self-stufy phase. Classes will meet online, on Wednesdays, for six weeks through August and September. Planning a vacation in the middle of summer school? It’s fine - we can schedule a make-up online session when you get home. I’m also willing to try and make other accommodations to help make this an effective learning experience for everyone. All of these classes assume a basic level of PowerShell knowledge, although you’ll get plenty of review material to help you catch up, or dredge up old memories from when you last tried to learn the shell. Tell a friend, tell a colleague - I don’t do these kinds of offerings all that often; my travel schedule usually precludes it. But a fortuitous schedule has made it possible, so consider taking advantage!
The PowerShell.org TechLetter goes out once a month, and we’re looking for an editor to take over the task of building each monthly issue. You’ll need some basic HTML knowledge, and ideally will have a decent HTML editor. Not FrontPage. You’ll be given articles in both HTML and Word format, and will need to insert those into a master HTML document and (especially in the case of Word), fix the formatting. You’ll have plenty of examples from past issues to work with. Eventually, you’ll also schedule the mid-month mailing. It all takes a few hours once you have the monthly materials in hand, and you’ll usually have at least a week to do assembly and mailing. You’ll be helping us deliver technical content to a growing audience of more than 3,500 IT professionals and PowerShell enthusiasts! If you’re interested, contact me. Your pay will be double what I’m currently paid to do this. Which is, sadly, nothing.
UPDATE 2 JULY 2013: Microsoft is informing MVPs that the fix is in, and new help files should be downloadable by (at latest) the morning of 3 July 2013. So get your Update-Help ready to run. More info. If you haven’t recently run Update-Help… don’t. There’s a problem with the help files that have been produced recently so that instead of: **-computername ** You’re getting: -computername This affects all parameters - no value types will be shown. This has been reported to Microsoft, and they’ve acknowledged receipt of that report and are investigating. Personally, I believe the problem may be related to internal-use-only tools that are used to create the syntax section of the help files, so hopefully it’ll be an easy fix. The -full and -detail help still shows the correct information, so if you’ve downloaded the borked help files, you’re not totally out of luck. As far as I can determine, this only currently affects core PowerShell cmdlets, not add-in modules from product teams like Exchange, etc. I believe that’s because the core cmdlets were just updated and re-published, something the PowerShell team tends to do a bit more frequently than some of the other product groups. I’ll keep you posted as I learn anything new.
As the Scripting Games begin to wind down, I know that we’ve come across a number of divergent opinions, especially in the comments. “You shouldn’t use .NET classes!” says one comment, “you should have done this with a .NET class” says another comment _in the same entry. _Fun. It’s great to see those differences - but it’d be better to discuss them. So I’m asking everyone in the Games: Go through your comments on all of your entries. Find comments that you disagree with - but that you could possibly see someone making an argument for (and that you’d perhaps argue against). Post those here as a comment, or email me (there’s a contact form on the Site Info tab). I want to collect these, and start a series of discussions where we can, jointly, start to hammer out some patterns and practices that we, as a community, feel work well. Some of those may have exceptions (rules always do) - “never use a .NET class _when there’s a cmdlet that can do the same thing, _but otherwise go nuts” is one example. Fire away. For now, you don’t need to put your argument for or against - I’m just collecting the topics that we’ve seen disagreement or differing opinions on. Discussion will follow! The result of this will be a community-guided Best Practices ebook, which I’ll assemble and we’ll give away for free. I might even build that, initially, as a wiki, so that folks could contribute to it over time. Will see - that’s a bit of extra software.
Here’s what I know, much based on a TechEd talk this week: We can expect PowerShell v4 to ship in the Windows Management Framework, as with previous versions. It will be preinstalled on Windows Server 2012 R2 and what they’re calling Windows 8.1; the default execution policy will be RemoteSigned, and on the server OS Remoting will be enabled by default. Microsoft’s past policy has been “current version and two back,” and if they follow that then we’ll get WMF 4.0 on Windows 7, Windows Server 2008 R2, and later. That would leave out Server 2008, if in fact they follow that same policy. DSC itself starts with a PowerShell script that’s mainly declarative code: Make sure x is installed, make sure y isn’t installed, etc. PowerShell compiles that into a MOF, which can be transmitted to managed endpoints (computers). The built-in mechanisms for deployment aren’t as complex or flexible as GPO or SCCM targeting, but you could use either GPO or SCCM to deploy those MOFs. That’s the “push” model - you push MOFs out to managed nodes. A “pull” model requires you to configure managed nodes to have a URI and UDDI, and they check that URI for their MOFs. DSC runs every 15 minutes or every 30 minutes by default, depending on whether you’re using push or pull, and you can configure that time. Right now there’s no feedback or reporting - it’s a bit like GPO, where you push out the setting and it enforces it, but that’s it. When DSC runs, it takes your “desired state” MOFs and starts running “DSC resources.” These resources are special modules that implement a predefined set of functions - a Get, a Test, and a Set function, to be specific. I expect MS product groups to provide these - the Exchange team will likely someday provide resources that can check/set Exchange settings, for example. You can also write your own modules. DSC calls the “test” to see if your setting is or isn’t configured at that time; it calls the “set” to add/remove/whatever the setting. So the real work is done by these special modules - and those modules can do whatever they want. Write to the registry, run commands, call .NET classes, anything. So there’s two scripts: The “desired state” script that gets compiled to a MOF (so you shouldn’t ever have to mess directly with MOFs yourself), and the “implementing module” that has the three special functions which actually do all the work. In the “pull” model, those special modules can be dynamically downloaded by a managed node. “Hey, I grabbed this desired state MOF, and it seems to require 12 modules, so I’ll go to the same URI and look for those 12 modules.” You provide those modules as ZIPs, and PowerShell can grab the ZIP, expand it into the proper location, and then run the modules as needed. Personal analysis (meaning this is my opinion, not something MS has said): I can see this DSC feature integrating super-well with some future version of SCCM. DSC writes out some local file with configuration details, and the SCCM client grabs it and feeds it up to the database. Those MOFs could potentially be pulled from a Distribution Point by the client, handed off to PowerShell, and run on a scheduled basis. I can also see DSC starting to supplant GPO in a lot of ways. After all, most GPO stuff is just reg hacks in a special section of the registry; there’s no reason DSC couldn’t do that - and it does it on a more frequent basis, making it more reliable. Right now, the targeting of a MOF isn’t as flexible as GPO targeting… but that could obviously evolve. Until more of the architectural details emerge, we won’t know for sure… and this is of course a v1 feature that will doubtless be expanded on and invested in as the team moves forward. We do know that the first release of DSC will not have a lot of those underlying “resource modules,” which means you won’t actually be able to configure much. This is a feature the team needs to put in place so that folks can start building those things… so this is going to take a cycle or two to start being really useful. There’s obviously still a lot under wraps here, and this is all subject to change and tweaking as the team moves toward release. We’re told there will be some kind of public preview - but they haven’t announced a date on that. Personally, with the Build conference coming up, we can imagine that Microsoft will try and have a preview release ready for that show. There’s also no announcement of ship date. It’s still too early to tell, and I want to emphasize that the company hasn’t announced any dates. We can but try to make educated guesses at this stage.
Yesterday at TechEd North America, Jeffrey Snover and Kenneth Hansen began describing features to be delivered with PowerShell v4 in Windows Server 2012 R2 (the company has not yet announced availability dates for either). In particular, a new feature called Desired State Configuration promises to become the foundation for some pretty serious expansion. Essentially, DSC lets administrators write a declarative “script” that describes what a computer should look like. PowerShell takes that, matches the declarative components with underlying modules, and ensures that the computer does, in fact, look like that. Nearly anything can be checked and controlled: roles, features, files, registry keys - anything, in fact, that a PowerShell module can do. The architecture includes the notion of centrally stored declarative scripts, and the ability to dynamically deploy supporting modules on an as-needed basis to computers that are checking themselves. A System Center Virtual Machine Manager demonstration utilized the feature to dynamically spin up brand-new VM instances and have them immediately reconfigure to their desired state. At first glance, it’s easy to see “more Microsoft stuff” in this feature. After all, the company has previous given us Dynamic Systems Management (DSM), various universal “configuration languages,” and even System Center Configuration Manager’s somewhat primitive configuration auditing feature. But keep in mind that DSC will be a core part of the OS. That means product teams and ISVs can rely on it being there, with no other dependencies to worry about. DSC is also built around DMTF standards - like the MOF format - making it natively suitable for cross-platform management. A demo from Opscode using their Chef product showed clever use of the new DSC feature. Hansen also mentioned that PowerShell modules will be deployable through DSC as ZIP files, helping make them more self-contained (not entirely unlike PECL packages in the Unix world). There has been no announcement as yet on how far back PowerShell v4 will be made available, nor whether or not DSC is a PowerShell feature or a Windows Server 2012 R2 feature. If it is indeed a PowerShell feature (which I suspect it is), then it’ll be available on any system with v4 installed. That will hopefully include at least Windows 7, Windows Server 2008 R2, and later.
I can honestly say that the interactions that I"™ve had with the PowerShell community over the past five years have been some of the most fulfilling. There is something to watching someone learn to script. Some plateau artificially mainly because they don"™t want to leave the GUI. Often they"™re forced into learning PowerShell and stubbornly go into trying to learn as little as possible. If you competed this year you do not fall into that category. You fall into the category that I love working with Talented Specialist that we watch graduate from good to great. I"™m happy to invite this year"™s class into “the club”. For everyone else I have an invitation. If you would like to know what makes a good script great and will be in New Orleans next week for TechEd 2012 NA, then please join the judges of the Scripting Games as we do a public Code review. Simply put we"™ll take a script and as a group discuss what makes it good and bad. We"™re calling it best practices for the real word, but you"™ll see it listed in the directory under BOF-ITP23.
