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:
Creating windows shortcuts are usually done through the New Shortcut Wizard, MSI files, Group Policy Objects, or even a simple file copy. Shortcut files are .lnk files that Microsoft Windows uses for shortcuts to local files while .url is used for destinations such as web sites. As we all are aware, the .lnk filename extension is hidden in Windows Explorer even when “Hide extensions for known file types” is unchecked in File Type options. The reason for this is the NeverShowExt string value in HKEY_CLASSES_ROOT\lnkfile. Shortcuts are also displayed with a curled arrow overlay icon. The IsShortcut string value causes the arrow to be displayed. For a full run down on creating shortcuts and favorites with PowerShell head over to PowerShellBlogger.com.
When you are wanting to run code remotely, it’s common to do this via the use of Invoke-Command (though other options exist, such as through Start-Job for example). The biggest downfall to date i’ve found with remoting is the lack of an option to combine the use of your local functions within a ScriptBlock that has other code in it. As an example, the following is not possible:
function Add ($param1, $param2) { $param1 + $param2 } function Multiply($param1,$param2) { $param1 * $param2 } Invoke-Command -ComputerName $env:COMPUTERNAME -ScriptBlock { $addResult = Add $args[0] $args[1] $multiplyResult = Multiply $args[0] $args[1] Write-Output "The result of the addition was : $addResult" Write-Output "The result of the multiplication was : $multiplyResult" } -ArgumentList 3, 2 However, there is a way to achieve this type of operation, and make as many local functions as you want available to be used and combined with other code in your ScriptBlock. You can find the full article at powershell.amsterdam.
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.
Its a new year with new goals and I hope to provide even more assistance and value to the PowerShell community in 2016. I have created a new Boston based PowerShell user group and will be working hard on creating sessions as frequently and regularly as possible. If you are in the greater Boston or New England area please join the user group. If we have any Microsoft employees or PowerShell MVPs visiting the Boston area in the future, we would love to have you deliver a session. I have arranged booking of a room in the Microsoft Technology Center located at Kendall Square, 255 Main Street, Cambridge, MA 02142 when required. I will also look into offering the meetings over Skype for Business if possible. Check out and join the Boston PowerShell User Group here: http://www.meetup.com/Boston-PowerShell-User-Group
Hey everyone, hope you had a great 2015 and I am back with I hope to be weekly updates for everyone at PowerShell.org. I wrote up a quick article on how to retrieve the last reboot time or the current up time for any local or remote computer. I also include a function that can be used to query remote computers as well. There may be a situation where you want to determine whether you take action depending on the last reboot time, or you may simply want it to be displayed for debugging or logging purposes. You can check out the full article over on PowerShellBlogger.com.
Hopefully, you’re aware that Microsoft is moving to UserVoice for accepting feature requests and bugs. DSC in particular has 30-odd suggestions at present, and I thought I’d run through some of my fav’s. Log in and up-vote the ones you like, or add comments to expand the discussion!
Change the Pull Server database to SQL Server. Broadly, this is a great idea. In theory, you should be able to modify the web.config file and direct it to a SQL Server already, but nobody knows the database schema that the pull server expects.
Refactor the LCM’s validation logic. This is another of mine, and it’s crucial. Right now, only the LCM can validate multiple partial configs and tell you if there’s a validation problem like a duplicate key. This means our only possible point of failure is the target node, which is the worst possible place for that to be. Factoring the logic out would let us built a pull server that could combine multiple configurations _server-side, _and spit out a combined, pre-validated MOF for the target to consume. We could also use the configuration logic to manually combine and validate MOFs in a test or RSoP mode, perhaps with a cmdlet.
There’s plenty more - have a look, vote for ones you like, and add your own suggestions! And there’s a lot more besides DSC in there - see anything that you think is important?
In Microsoft’s brave new world of agile, more-frequent software releases, including numerous pre-release cycles… Microsoft needs to rethink the way it communicates versioning. Windows Management Framework (WMF) v5 has, for me, been pretty much the perfect example of what not to do, and the perfect example of Microsoft still shoehorning itself into old nomenclature that no longer fills the bill. I know a bunch of folks on the PowerShell team are probably still trying to figure out what works, too, so this isn’t meant to be a hammer-on-’em post, but WMF5’s lifecycle was, from a versioning perspective, pretty hellish. We had several “technology preview” releases, which were simply named after their month of release. April 2015. November. Whatever. It was really difficult from within the product - e.g., via $PSVersionTable - to tell which one you were running, which made helping people difficult. None of these were supported in production until the “WMF5 Production Preview” released in late 2015, and in December we got “RTM” code. RTM means “Released to Manufacturing,” which is kind of absurd as a milestone, because there’s literally zero actual manufacturing going on. It’s just a word Microsoft is used to using. Windows 10 shipped with a production-supported version of WMF5, but it still wasn’t “final,” meaning RTM WMF is better than what shipped with the RTM OS. God willing, what ships in Windows Server 2016 will be v5.1 or something, because if we get yet another 5.0 release folks are going to start throwing up their hands and quitting. Now that Microsoft’s all lovey-huggy with open source and Linux and stuff, can we just copy what those guys do? Every time you release code, increment the version number. It’s that simple. There’s no “production preview,” there’s just “5.3.” And you maintain a list of what’s supported in production. If 5.3 isn’t a production milestone, fine - say so. But it’s still a real version, because it was released unto the world. The next release is 5.4. Then 5.5. And maybe 5.6 is supported in production, but once 5.7 is out, 5.6 remains supported for only 90 days. Or whatever. Just have a list of what’s supported, and increment the version number every time you release it. 5.8 might only last a week before someone finds some heinous bug and releases 5.9 - that’s fine. After that comes 5.10, and then 5.11, and so on. 6.0 is the first release of a major new evolution in the product, and it’s probably a “preview” release. 6.1 will be a bit better, with fewer bugs and more features nailed down, but it won’t be until maybe 6.5 that we get a “supported in production” release. All of this is a lot easier to keep track of than vague “version” numbers like “April 2016 Production Preview.” And while we’re at it, let’s have a Get-PSVersionInfo cmdlet. It can wrap around the existing $PSVersionTable variable, of course, but it can also ping a web service on Microsoft.com to tell you what the latest version is, what the latest supported version is, and whether or not your current version is supported in production. OMG, that would be _wonderful. _
Want to see what a real-world, functional, production-grade DevOps environment looks like? Look no further than Amazon Web Services’ Elastic Beanstalk (EBS). EBS is a neat combination of their EC2 IaaS product, S3 storage, and some DevOps magic. From a working perspective, it goes something like this:
Developer checks code into Git. A portion of this code is actually a set of EBS directives, outlining changes that need to be made to the base operating environment. This can include things like setting environment variables, installing packages, and so on.
Someone indicates that what’s in GitHub is ready for release. You can do this by pushing a button in your AWS console, or by making a call to AWS’ REST APIs. It’s pretty easy to automat this step.
AWS spins up virtual machines, and reads the EBS directives to get that environment configured the way it’s supposed to be. The code is loaded from Git into the VMs. The VMs are registered with AWS’ load balancer, and whatever old VMs were running are de-registered and destroyed. Poof, your app is up and running.
This model accomplishes the basic goal of DevOps, which is to shorten the path between developers and users. So where’s the “Ops” role in all this? Amazon did it. Their contribution to ops was to create all the automation necessary to make these steps happen. And the beauty of this model is that it supports tiered environments. For example, the above three steps might serve to spin up a testing environment, where you then run automated tests to validate the code. If the code validates, it’s pushed into a production tier - all automatically - running on a separate EBS application. So from check-in to in-production is entirely automated, and the process can be performed consistently every single time. Now… what would this look like in a Windows world? In Step 1, imagine that instead of a set of EBS configuration directives - which are just text files - your developers create DSC configurations. Yes, the developers. After all, they’re the ones who are coding for the environment, so that DSC configuration documents what they need the environment to look like. You might have a second DSC configuration that documents corporate standards for security, manageability, and so on. Whatever. Step 3 might be Microsoft Azure Pack or System Center Virtual Machine Manager, told - perhaps via an SMA automation script - to spin up the new VMs from a base OS image. The DSC configurations are run to produce a MOF, which is injected into the new VM. The developer’s code is deployed to the VM. The VM is registered with DNS and perhaps a load balancer, which provide access to it. There are a couple of important details that I’ve glossed over a bit. Jeffrey Snover is fond saying, “treat servers like cattle, not pets.” But servers by their nature have to have a few unique pieces of information, right? Well… yes and no. For all I know, cows make up names for themselves. I just don’t care. Take IP addresses, for example. You shouldn’t be assigning static IP addresses to servers; your DHCP system should be highly available, fault tolerant, and set up to handle servers. As you spin up a new VM, you can obviously have it register itself with DNS, so the IP address is mapped to a hostname. And speaking of that hostname - you as a human never need to know it. Or you shouldn’t. Windows will make up a host name for itself as the VM spins up, and you can - through your automation scripts - capture that host name. That lets you set up DNS CNAME records, a load balancer, or whatever else. The point is that while the server may have made up a name for itself, you don’t care. Nobody will ever address that server by its host name - they’ll use an abstraction, like a load-balanced name, or a CNAME, or something else. Your automation scripts handle the mapping for you. When a VM is spun down, automation de-registers the dying host’s name from whatever, closing the lifecycle loop. Interestingly, you could probably do this exact model, today, with a huge number of applications in your environment. Why bother? I mean, this model makes sense in web apps where you’re constantly spinning up and destroying VMs, but what about the majority of your apps that just run all the time without change? Well, this same model could spin them up in a disaster recovery scenario. Or in testing environments, which are constantly re-created to provide “clean” tests. Yes, it’s a lot of investment up front to make it all work, but once it’s set up it just runs itself. And that’s what DevOps looks like.
After a two week hiatus I am back this week with a quick write up on how to automate the updating of PowerShell help. Update-Help should be one of the first things typed in PowerShell on a new workstation build. I jump into the topic and demonstrate how to automate the updating of the help files from the Internet or from a local network share. You can view the full article over at PowerShellBlogger.com. I look forward to getting another article out to everyone next week and I hope everyone in the US enjoys their long weekend!
