If you use F5’s BIG‑IP Local Traffic Manager (LTM) for load-balancing, then you may find the new PS module I’ve written helpful. The module uses the REST API in ver. 11.6 of the LTM to query and manipulate an F5 LTM device. You can add and remove members from a pool, enable and disable them, and find out what pools a member is in, among other things. I’ve made the module files available here. I welcome all comments. A few notes: Since the module uses the Invoke-WebRequest cmdlet, PowerShell 3 or higher is required. Also, since some F5’s utilize self-signed certificates, and Invoke-WebRequest is unhappy if part of the certificate chain isn’t trusted, I’ve included a dependency on Jaykul’s PS module TunableSSLValidator, which allows for temporarily ignoring certificate errors. If you’re using a trusted certificate chain, then you don’t need the TunableSSLValidator module and can remove the -insecure flags from the Invoke-WebRequest calls. Cheers, Joel
First off - thank you to everyone who participated in the version control survey! We’ve had a fun few weeks - Somehow the PowerShell Summit, Build, and Ignite were scheduled back-to-back-to-back. Among a host of other announcements and tidbits, we found that Microsoft has open sourced the DSC resources on GitHub, that Pester will be included in Windows, and saw a cool demonstration from Steven Murawski on using Test Kitchen to test DSC resources. These and other solutions and technologies are starting to assume you know how to use source control, and many require having a source control solution in place - how do you automate testing and deployment on a commit, if you have nothing to commit to? Source control has long been an important component of IT, but it seems IT professionals, particularly those in Microsoft environments, aren’t consistently using it. You might expect a gap between IT professionals and developers, but less than 50% of IT pro respondents used source control as a team. Breaking down the IT professional population by environment, we see that Microsoft environments are even further behind. Many PowerShell aficionados work on teams that aren’t using version control. Long story short? IT professionals, management, and vendors have work to do; these new tools and ideas that rely on source control are great, but we need to work on finding a horse for the cart. The rest of my rambling analysis can be found here. If you want to get up and running quickly, consider using GitHub for your PowerShell projects. You can start with the easy-to-use GUI client, and drop into the command line when you want to get your hands dirty. It’s a great way to start learning about source control, and to get involved in the community. Do you have any suggestions on how we can get to a place where using source control is common place for IT professionals? Is this a worthwhile goal? Sound off in the comments!
Edit:The results are in. I was watching Don and Jeffrey’s PowerShell Unplugged session from Ignite the other day, and something stood out. At 30 minutes in, Don asked the crowd whether they were using source control. Based on the video, the crowd wasn’t big on source control. I work in IT. If I asked that same question at work, I would likely get a similar response. Why is that? Source control is incredibly important and can drive a number of other processes, yet it seems to be an afterthought for many IT professionals. I drafted up a quick, informal survey on source control for IT professionals. If you have a moment, would love to see your responses. Stay tuned for a rough analysis and write-up on the results [Edit: Results are in]. Cheers!
I had a good deal of yard work to do this weekend; I see yard work in a similar way that a click-next-admin sees Windows PowerShell. I want no part in it. So I wrote a quick bit on how we can deal with the click-next-admin. Jeffrey Snover recently gave a TechDays Online session where he candidly asked us to “make today the last day you hire a click next admin.” This is a fantastic goal, but how do we get there? There’s no set answer, but I listed out some of the major challenges I see. Would love to hear your feedback and ideas - flip through the post and stop back here to discuss! If you’d like to have some fun, share your click-next-admin stories on twitter with the #ClickNextAdmin tag. Aside: Thank you for the invite to contribute here, it’s an honor. Cheers!
There was a brief and lively discussion on Twitter recently stemming from someone asking for advice on how to convince management to turn on Remoting. “Fire Management, if they have to ask” was apparently not an option, although it should have been. I mean, at this stage, you either know the value of PowerShell and its Remoting technology, or you’re being willfully ignorant. But that wasn’t where the discussion got lively.
Not too long ago, over on DonJones.com, I wrote an article that tried to explain some of the confusion between Microsoft’s World of Management Instrumentation - e.g., WMI, OMI, CIM, and a bunch of other acronyms. I glossed over some of the finer details, and this article is intended to provide more specificity and accuracy - thanks to Microsoft’s Keith Bankston for helping me sort things out.
CIM and the DMTF
Let us begin with CIM. CIM stands for Common Information Model, and it is not a tangible thing. It isn’t even software. It’s a set of standards that describe how management information can be represented in software, and it was created by the Distributed Management Task Force (DMTF), an industry working group that Microsoft is a member of.
