ChatOps is a term used to describe bringing development or operations work that is already happening in the background into a common chat room. It involves having everyone in the team in a single chat room, then bringing tools into the room so everyone can automate, collaborate and see how automation is used to solve problems. In doing so, you are unifying the communication about what work gets done and have a history of it happening. ChatOps can be supplemented with the use of tools or scripts exposed using a chat bot. Users in the chat room can talk to the bot and have it take actions on their behalf, some examples of this may be:
I am back this week with a quick how-to article on delivering, installing, or launching version controlled files. In the past I ran into problems when having administrators launch my PowerShell tools from a network share. The performance was slow when launching it across the WAN, and the file would often be locked when I tried to replace it with a newer version. I came up with a solution to the problem by using none other than PowerShell. The solution dips into all kinds of PowerShell techniques including local environment variables, getting text file contents, file version checking and even shortcut (.lnk) creation. If you are also a user of Sapien’s PowerShell Studio, then definitely give this one a read. Check out the solution over on PowerShellBlogger.com.
Thanks to all those who participated in the PowerShell Editor Services Hack Week last week! Much progress was made on fixing bugs and adding new features to both PowerShell Editor Services and the PowerShell extension for Visual Studio Code. Here’s a quick summary of the contributions that were made during the week: Variable Display Improvements in the Debugger Keith Hill made many great improvements to how we display variable contents in the Visual Studio Code debugger. First of all, he added support for variable scopes other than just “Local” as we had before. You can now inspect variables from both the Global and Script scopes. You will also see a special “Auto” section which filters the set of variables down to those that were defined in the current scope. This is really helpful for quickly checking the state of the variables in your functions! He also added greatly improved the variable value display for collections such as arrays and dictionaries and also objects which implement the ToString() method in .NET. You will now see much greater detail for these variables in the debugger: New Expand Aliases Command Doug Finke contributed a new “Expand Aliases” command which searches your script file or selection for the use of cmdlet aliases. For any alias it finds, it replaces the text with the full command name. This is helpful for developers who want to quickly write out scripts using aliases but resolve them to their command names before committing to source control. Here’s a GIF of the feature in action (click to play!): Sublime Text Editor Integration Work on the integration of PowerShell Editor Services in Sublime Text has progressed quite well this week. The basic protocol implementation is now working, enabling language features to be integrated over time. I’ve also implemented basic file management support so that opened files are sent to Editor Services for syntax checking and semantic analysis. From this point it’s just a matter of integrating the language features of PowerShell Editor Services into Sublime’s UI using its plugin API. Check out the current code in the editor-services branch of my fork of the PowerShell Sublime Text package. Once this effort is stable enough for an initial release, I’ll be submitting a PR back to the original PowerShell Sublime Text package repo and future work will continue there. Atom Editor Integration Some work was started on an integration with the Atom editor but it was quickly determine that Atom’s APIs for language features were to sparse to make quick progress. However, with the experience gained from the Sublime Text integration, future work on the Atom integration should be much easier. Expect to see more effort in this area in the first half of 2016. Miscellaneous Improvements
Do you wish your favorite editor had better PowerShell editing support? Do you have a great idea for a new feature for the PowerShell extension in Visual Studio Code? We’re dedicating next week, December 6th through 13th (Sunday through next Sunday), to hacking together on new features to enable better PowerShell support in any editor! Here’s the plan: On Sunday, December 6th at 11AM-12PM PST (7-8PM GMT) I’ll host a Crowdcast event to give an overview of PowerShell Editor Services, the PowerShell extension for VS Code, and other general ideas for contributions that people can make. Participants can join to ask questions and discuss potential ideas so that we can get the ball rolling. Once hacking has started, we’ll hang out together in the #editors channel of the PowerShell Slack Community so that everyone can get help on their contributions. We’ll be using these discussions to help flesh out documentation about these projects using the GitHub Wiki. Every question asked will be helpful so don’t be shy! On the week following our hacktivities, I’ll release new builds of PowerShell Editor Services and the Visual Studio Code extension containing our collective efforts. I’ll also post a follow-up report here on PowerShell.org with details about all the contributions that were made in this time.
Convert-WindowsImage.ps1 is a very popular method to create VHD’s with. However it’s not a module, and in it’s current form cant be added to one.
So I have started a new project on GitHub called WindowsImageTools and posted the results to the PowerShell Gallery.
It has a few functions so far. Convert-Wim2Vhd, to do the work, and New-UnattendXml because it hate having to edit XML to make minor changes. The resulting XML is universal in that it works on both 32 and 64 bit and will do a silent install (currently on Volume Media only). Then it auto-logs on the Admin and run a PowerShell script to kick off what ever you need bootstrapped (like DSC)
Automation is awesome, but what if you need to run a script with elevated privileges? If you are following security best practices then the account you login with most likely doesn’t have the required elevated privileges. Storing your password in plain text in your scripts is no good either. So what do we do? There are several options and each has there place, but I’ll show you my favorite below. Check out the full article by clicking on the link below. While you are there check out some of my other posts, the script repository and the resource page.
If you’ve been a sys admin for more than a week you’ve probably heard this…“I’m locked-out, help!”. Normally the user has made their way to your cube and is impatiently tapping their foot waiting for you to magically solve there problem. So you find their account, reset their password and everything is right with the world…Or is it? Two minutes later they show up again because their account was locked-out before they even got back to their desk. Now what do you do?
Hello Powershell.org! This is the first time I’ve posted for anyone outside of my own powershell blog site PowerShellMasters.com and I just want to thank PowerShell.org for everything they do for our community. I think most of you would agree that this site is one of the best PowerShell sites out there today and I am grateful for the opportunity to reach so many PowerShell people. OK enough with the touchy-feely stuff. 🙂
Take a minute think about how many PowerShell scripts you have written for yourself or your team. Countless functions and modules, helping to automate this or fix that or make your teams lives easier. You spend hours coding, writing in-line help, testing, packaging your script, distributing it to your team. All that effort, and then a lot of the time the script is forgotten about! People just go back to doing things the manual way. I put this down to being out of sight, out of mind. Users who do not use the command line regularly will quickly forget about the amazing PowerShell-ing that you did to try and make their lives easier. Then there are are other problems, like working out the best way to give end users permissions to use your function when they aren’t administrators. Do you give them remote desktop access to a server and only provide a PowerShell session? Setup PowerShell Web Access? Configure a restricted endpoint? I thought the point of this module was to make your life easier, not make things harder! These problems are what an open source tool called Jenkins can solve for you. Traditionally used by developers to automate their build process, it can be leveraged to wrap web interfaces, job tracking and scheduling around the PowerShell scripts you worked so hard on. The below image shows what a Jenkins build looks like. In this basic example, the the build creates a text file on a remote machine by using PowerShell Remoting and the Set-Content CmdLet**. **The parameters for these commands can be entered into the form, and will be passed to your PowerShell script via variables. To find out how to start leveraging Jenkins in your environment, take a look at the below blog posts:
We all know that working with WMI/CIM can be frustrating. So little of it is documented, and it can be tough to find the class that has the exact info you need. A long time ago, SAPIEN released a very nice WMI Explorer tool that, recently, was taken offline. The reason is that the company was producing an all-new, from-scratch replacement - and it’s now available. Their new approach is pretty interesting. Rather than just live-browsing the local WMI repository or a remote computer’s repository, the tool can now go through the repo and actually create a local cache. That cache is optimized for searching, making it a ton easier to search not only for class names, but also for property names and more. Even property values! So if you know (for example) that “Windows 8.1” is part of some property of some class, this tool can help you find where it is. It also provides in-product links to what online WMI documentation exists, making it quicker to get to that stuff. Although the old tool was a freebie, this new one will set you back $40, and I imagine it’s included with the $789 kitchen-sink bundle the company sells. While I miss the free tool, this new one is significant enough that I’d pay for it. After all, money is what keeps the programmers at SAPIEN employed, so we can’t expect great tools for zero money. Frankly, this new WMI Explorer is one of the very, very, very, very few tools that’s going to earn a place in my base VM images that I use in classes - simply because it’s so useful. The ability to search for property values gives me a whole new approach to finding the exact WMI class I need. It’s a well thought-out tool. Now, it’s not “zero footprint” like the old one - but the old one didn’t do nearly as much, like creating a local, searchable cache of the repo. Also, this isn’t something I’d install on all my servers. There’s no need - you install it on your computer, and let it reach out to key servers to discover their repositories. So it’s “zero footprint” on the server, which is all I care about. That cache means I can even browse a remote machine’s repo when I’m completely offline, like on an airplane working on a book. That’s a huge deal for me. SAPIEN’s blog article on the software release includes another interesting fact: They plan to release a new line of smaller tools like WMI Explorer, and either sell them separately or as a community package. Cool! But what’s even cooler is this: _“The proceeds from these tools will go towards supporting user groups and non-profit organizations.” _Well, damn. So that $40 isn’t even funding the development of the tool per se, it’s funding (in part) your local user group. That’s awesome, and makes it well worth the standalone purchase if you don’t own the whole Software Suite already. As usual, SAPIEN offers a free trial. Give it a whirl.
