The SHiPS module has several use cases with structured data. I have written a few proof-of-concept modules using SHiPS to understand how it works and try out different design patterns.
One of my sessions at PowerShell Conference EU 2018 is around using SHiPS. In the process of creating different demos for this session, I started implementing PS drives for several different things. One such module I created enables the ability to browse PowerShell Conference EU 2018 agenda as a PowerShell drive. I have an initial draft of this module at https://github.com/rchaganti/PSConfDrive.
How to install the module?
Since this is still a very early version of the module, I have not published it yet on the PowerShell Gallery and you need to download the zip archive of the GitHub repository and extract it to a folder represented by $env:PSModulePath. You will require the SHiPS module as well. This can be downloaded from the PowerShell Gallery.
Install-Module -Name SHiPS -Force
The following commands will load the modules and map a PS drive.
Here is how you can use this PS drive for exploring the conference agenda.
Once again, this is a POC only and the design still needs to be and can be optimized. If you plan to attend PSConfEU 2018, come to my session on SHiPS to understand how to use the module and choose the right design pattern for your modules.
The US-based “PowerShell and DevOps Global Summit” sold out in record time this year, and the European “PowerShell Conference EU” (psconf.eu) is filling quickly. Both take place in April 2018. If they are new to you, then it’s probably because they are community-organized events, without a profit intention and with no huge marketing budget. While it’s too late for the US summit this year, psconf.eu still has capacity.
As a co-organizer of psconf.eu, I’d like to walk you through this year’s event and some of its ideas. Here is the official AfterMovie from PSConfEU 2017.
psconf.eu 2017 Official AfterMovie - YouTube
Psconf.eu takes place this year April 17-20, in Hanover, Germany. The full agenda and last-minute information are available at www.psconf.eu.
There is no doubt that PowerShell is an essential skill set for modern administrators, and it has always evolved. When you look at the PowerShell ecosystem in the past 12 months, though, you’ll see an unprecedented pile of changes, some of which are transformative and even disruptive.
PowerShell went open-source, PowerShell Core 6 goes cross-platform and reaches out to Linux and macOS, admins are faced with two PowerShell “editions”, and Windows PowerShell is frozen. It’s an exciting mix of opportunities (reaching out to Linux/macOS, managing heterogenous environments, using PowerShell in the cloud) and deep desire for guidance (will I have to rewrite scripts with PowerShell Core 6? How can I develop code that works in all PowerShell editions? How safe is it to continue to rely on Windows PowerShell 5?).
Problem is: you can’t attend classes or get books for answers to any of these questions. Once there are classes or books, they would inevitably be outdated again. Classes and books are great for fundamentals, but too static to cope with cutting edge topics, and Microsoft has been pretty cutting edge lately.
As an admin in a small shop, you may get away with ignoring the latest developments for a while. As a consultant or admin in larger enterprises, you cannot. First-hand & cutting-edge information is what your future decisions are based on. It drives your business. Guaranteeing state of the art and safe operations is a must.
That’s why PowerShell conferences are partially serving the training for hot topics these days and feel more like an intense advanced training for experienced PowerShell professionals. Instead of asking for permission to go to a conference, it would probably be more accurate to tap your training budget.
Should you feel you can’t get out of your job for 4 days, consider this: by bringing together experts from all disciplines to one location, and embedding them into a well-designed and rich agenda, surrounded by social and workshop events, these conferences provide the answers, guidance and orientation that save you endless hours of internet research, make sure you won’t reinvent the wheel, focus on future-proof techniques, and use the latest security guidelines.
Getting Orientation and Guidance
On day 1, we open the conference with delegate registration and then start together in the great historic Leibniz Saal. PowerShell inventor Jeffrey Snover kicks off the event with his keynote “PowerShell 2018 – State of the Art”, providing solid orientation and guidance: where do we stand, where do we go from here. Then, the conference fans out into three parallel tracks, most of which are delivered in English.
Some of these presentations dig deeper into PowerShell Core: Wojciech Sciesinski explains how to create future-proof PowerShell modules that are compatible with all PowerShell editions, and work cross-platform. PowerShell team members from Redmond showcase their current developments, Ben Gelens talks about new DSC, and German .NET Guru Dr. Schwichtenberg explains what to do with PowerShell on Linux, and summarizes the essential .NET knowledge any ambitioned PowerShell user should have.
No-Nonsense Sessions & Discussions
If you ever attended a classic conference, you know how exhausting it can be to listen to endless presentations and slide decks. At psconf.eu, all presentations are 45 minutes sharp, then open up in discussion. We want presentations to be concise and on the point, and prefer demos over endless slides. At the end, you have 15 minutes of Q&A. “Presentations are great, but coffee breaks are where you meet people” This is why psconf.eu has the highest coffee break ratio in the industry: Chat with the presenters, let the information further sink in, defrag your mind, and connect to others.
All materials will be downloadable, and sessions are recorded so you can replay them later. “Ask the Speakers” on day 1, “Ask the Experts” at every lunch, and the speakers and Microsoft finale at the end are all chances to get information for anything that wasn’t covered in the presentations. If you leave the event with a PowerShell question unanswered, then you did not ask.
This is a personal conference where you get to know people, and know whom to ask. That’s why there is a limit on the number of delegates, and why we have social evenings. The legendary evening event on day 1 takes place in “Yukon Bay” again, an ancient gold digger town in the heart of the Hanover Zoo. It will be a big “Hello” for the alumnis, and a warm “Welcome” to anyone new to psconf.eu. We’ll have great food and drinks, polar bears and seals, beer and wine, and the chance to hang loose and make new connections and friendships. Everyone hangs out, including speakers. You may want to continue to talk about PowerShell, but you may just as well just kick back and enjoy the evening, the likelihood of which raises over time and number of beers.
Security – Essential Knowledge to Boost Your Career
psconf.eu delivers 75 sessions and covers almost every aspect of PowerShell. It wouldn’t make sense to go over all sessions here. Visit www.psconf.eu instead and review the full agenda. Tip: hover over a session to view the abstract. The agenda is preliminary, and we hope to be able to implement a mobile-friendly version soon.
One topic stands out: Security. We want delegates to become security experts and really know the best practices and how to deal with unsafe code and attackers. “Investing in people” is the best protection you can get, and psconf.eu is the place where you can do this investment, and improve security awareness and skills:
Security expert Matt Graeber reviews “the current state of PowerShell Security Features and Bypasses”. This includes JEA (“Just Enough Admin”), and when used correctly, it can be tremendously effective to increase security by reducing the blast radius of a compromise. Jan-Hendrik Peters and Raimund Andree from Microsoft Germany show you how: “Hands-on JEA”, complimented by David das Neves and Julien’s two-slot “The PowerShell Security Best Practice Live Demo”.
That’s literally just the tip of the iceberg. Red Teams and nation state threat actors alike are using PowerShell obfuscation to evade detection. Come see how the author of Invoke-Obfuscation and one of the original PowerShell developers tackle detecting obfuscation with PowerShell’s Abstract Syntax Tree and science in Revoke-Obfuscation (“Revoke-Obfuscation: PowerShell Obfuscation Detection (And Evasion) Using Science”). Attackers constantly update their tradecraft, forcing defenders to quickly build, tune, deploy & maintain detections in never-ending sprints. Check out how applying DevOps practices & frameworks like Pester, ScriptAnalyzer, & custom fuzzers can drive robust methodology-based detection development (“DevSec Defense: How DevOps Practices Can Drive Detection Development For Defenders”)
Will Schroeder, one of the contributors of the “PowerShell Empire” post-exploitation agent, together with Jared Atkinson and Matt Graeber, sets up one of the three coding workshops on day 2 where you can get hands-on experience and learn how to check for security breaches in your own IT infrastructure.
Plain Good Old PowerShell Knowledge
Not every session is dead serious. The entire event is designed to have fun. Here are just a couple of sessions that are a bit eerie: Bartosz Bielawski dives into “PowerShell Yin-Yang: The Worst Practices and Tips & Tricks”: Every Yin has its Yang. Every Jedi has her Sith. Every bad practice can be balanced with an awesome trick. Join me to see the darkest places of PowerShell scripting universe so that you know what to avoid! Get to know tricks that will impress your peers and tips that will make your life easier!
At PSConfEU17, Mathias Jessen talked about regex, and some of its common applications. This year, he’ll dive straight-first into some of the most bizarre functions .NET regex offers – the outer edge cases. Staffan Gustafsson takes a deep look into the PowerShell type system, including examples on how you can use it to adapt standard and third party types to your own situation and workflow. And Jared Atkinson investigates .NET reflection and how to access the Windows API from within PowerShell.
So to wrap it up, we’d love to welcome you in Hanover! To register and reserve your seat, or review the agenda, please visit www.psconf.eu. Should you have any questions, please drop me a mail at firstname.lastname@example.org.
PowerShell Core is a cross-platform (Windows, Linux, and macOS) automation and configuration tool/framework that works well with your existing tools and is optimized for dealing with structured data (e.g. JSON, CSV, XML, etc.), REST APIs, and object models. It includes a command-line shell, an associated scripting language and a framework for processing cmdlets.
Once this custom repository is added, here is how you use the PowerShell Core artifact.
Select the Virtual Machines blade in the Azure DevTest Labs.
Click the VM, and then click on Artifacts and Apply Artifacts. In the search box, type PowerShell Core, and then click on the result in the Apply Artifacts blade.
Click on the artifact and supply the parameters required.
Package URL – The MSI URL for installing PowerShell Core. You can retrieve this from https://github.com/PowerShell/PowerShell/releases.
Install C runtime for Windows OS prior to Windows Server 2016? – Select True for Windows Server 2012 R2 or select False. This is needed for Windows Server 2012 R2 if you want to use WinRM for PowerShell remoting.
Click Add. This artifact installation might take a few minutes and once complete, you can access the install script verbose logs.
This is it. You can, of course, install these artifacts (Windows or Linux) at the time of Azure DTL VM provisioning itself. And, you can do this deployment via an ARM template as well.
In the above snippet, line 12 specifies express module with a version string ^4.16.2. The version string here is prefixed with a caret (^) symbol. NPM supports different specification strings. We can prefix the version string with a tilde (~) as well or simply use an asterisk (*) to mean the most recent version or latest version of the module. Through the use of version range comparators, version can be specified in multiple ways. The node-semver repository provides in-depth view into this.
From the node-semver page,
A comparator is composed of an operator and a version. The set of primitive operators is:
< Less than
<= Less than or equal to
> Greater than
>= Greater than or equal to
= Equal. If no operator is specified, then equality is assumed, so this operator is optional, but MAY be included.
For example, the comparator >=1.2.7 would match the versions 1.2.7, 1.2.8, 2.5.3, and 1.3.9, but not the versions 1.2.6 or 1.1.0.
The tilde (~) and caret (^) ranges can be used as well.
X-Ranges 1.2.x 1.X 1.2.* *
Any of X, x, or * may be used to “stand in” for one of the numeric values in the [major, minor, patch] tuple.
* := >=0.0.0 (Any version satisfies)
1.x := >=1.0.0 <2.0.0 (Matching major version)
1.2.x := >=1.2.0 <1.3.0 (Matching major and minor versions)
Tilde Ranges ~1.2.3 ~1.2 ~1
Allows patch-level changes if a minor version is specified on the comparator. Allows minor-level changes if not.
Caret Ranges ^1.2.3 ^0.2.5 ^0.0.4
Allows changes that do not modify the left-most non-zero digit in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.
When we talk about applications or software deployed in the infrastructure, we simply refer to the version of the applicationor software running in the infrastructure. At any point in time, we can look at the installed service or software and understand what version of that is currently running on the system. How about your node configurations? Does your node tell you what version of the configuration it is currently using?
For example, consider that you have a set of web server nodes and each configured using PowerShell DSC. As a part of the initial configuration, you deployed a set of web applications on the node. And, at some point in time later, you made multiple changes to the node configuration in terms of adding or removing web applications and updating application configurations. If multiple such source controlled configurations are deployed on each of these nodes, how exactly do you figure out what version of the node configuration is being used on each of the nodes? This can probably be achieved by a complete suite of tools but is there a way, today, you can do this by querying the node itself? The answer is no. At least, in the PowerShell DSC world.
One of the core concepts of Infrastructure as Code (IaC) is to version/source control your infrastructure configurations so that it becomes easy to track what version of the configuration a target node has and rollback to last known working configuration when needed. But, the compiled DSC MOF files do not carry this information today nor they are aware of any source / version control systems. They need not be aware as well.
At this point in time, I track my node configuration version by adding a DSC resource that caches the node configuration version information. As a part of the build process, I can update the version of the configuration using this DSC resource. When I need to know what version of configuration a node is using, I simply invoke the Get-DscConfiguration cmdlets. to verify that.
I packaged this DSC resource into a module of its own and published in my Github account.
ConfigurationDSC resource module
Through the ConfigurationDSC resource module, I plan to combine various resources that help in managing DSC based configurations in deployment pipeline. At this point in time, there is only one resource, ConfigurationVersion, which helps in tracking the version of the configuration document. Here is an example of a configuration document with the ConfigurationVersion DSC resource.
What I have shown here is only a workaround. This approach has both pros and cons. I rather want this added into the existing DSC feature set. If you see a compiled MOF, it has a few configuration meta properties. For example, from the above example, the compiled MOF has the following instance of the MSFT_ConfigurationDocument class in the MOF.
At times we need to set the physical adapter advanced properties such as VLAN ID. This can be done using the Set-NetAdapterAdvancedProperty cmdlet. However, when using DSC-based configuration management, it makes sense to configure these advanced properties as well using DSC resource modules. Within the automation that I have been working on for automated deployments of Storage Spaces Direct clusters, I have the need for setting adapter advanced properties and that is what triggered me to write this new resource module — NetworkAdapterProperty. This is a part of the NetworkingDSC module.
This is not a fork of the xNetworking module. I am adding only the resources that I am developing from scratch to this NetworkingDsc. These resources will follow the HQRM guidelines.
Key property to uniquely identify the resource instance.
Name of the network adapter.
Display Name of the advanced property.
Value to be set on the advanced property.
Specifies if the property needs to be configured (present) or reset to its default value (absent).
The display name of a network adapter advanced property can be seen by using the Get-NetAdapterAdvancedProperty cmdlet. Depending on what the network adapter driver implements, this list changes between different network adapter models/vendors. Let’s see a couple of examples of using this resource.
Configuring VLAN ID advanced property
The display name of the advanced property for VLAN configuration on physical adapter is usually VLAN ID.
As a part of larger hyper-converged infrastructure (based on S2D) configuration automation using PowerShell DSC, I have written quite a few new DSC resource modules. FailoverClusterDSC was one of the modules in that list. I added NetQoSDSC as well to ensure I have the automated means to configure the QoS policies in Windows Server 2016.
This module contains five resources at the moment.
Enable/disable network adapter QoS.
Enable/disable DCBX willing state in the OS. This can be done at the global scope or for a specific interface.
Enable or disable 802.1P action priorities.
Create and configure QoS policies.
Create and manage QoS traffic classes.
Enable/Disable Network Adapter QoS
The NetAdapterQoS resource can be used to enable/disable QoS a specific network adapter.
This module, while code complete, needs some more work to declare as fully HQRM-compliant. I am working towards that by adding tests and better examples. Feel free to submit your issues, feedback, or PRs.
Using this provider, you can connect to local and remote Hyper-V hosts and browse the virtual machines and virtual networks as if they are folders on a file system.
Once again, like every other provider I am writing, this is experimental as well. I am writing these to understand what needs to be considered as part of the provider design and implementation. So, the final version of these providers may look and function differently.
– Add support for Hyper-V Host properties as leaf
– Fix support for using the module on a system with RSAT-ClusteringTools and not a Hyper-V host.
Simple Hierarchy in PowerShell (SHiPS) is a module that simplifies implementing PowerShell providers. If you are new to PowerShell providers, a PowerShell provider allows any data store to be exposed like a file system as if it were a mounted drive. In other words, the data in your data store can be treated like files and directories so that a user can navigate data via Set-Location (cd) and Get-ChildItem (dir or ls).
I have been looking at this and experimenting with a few providers of my own. I will write more about how to approach writing a PowerShell provider using SHiPS but wanted to give you a sneak peek into the Failover Cluster PowerShell Drive (FailoverClusterDrive).
Here is the Failover Cluster PowerShell Drive in action.
This is still an experimental module. SHiPS currenly supports only get actions. So, the mounted failover cluster drive will only be read-only. There are a few more additions I am still working on in my free time and I will push another release early next year.
Add support for Cluster Storage as a container
Add support for browsing cluster resource parameters as a container
Fix support for using the module on a system with RSAT-ClusteringTools and not a cluster node.
In the above pattern, I am creating a failover cluster and then adding the remaining nodes using the same configuration document. You can, however, have the node addition configuration using the FailoverClusterNode resource as a separate configuration document that gets enacted on the participant node.
The failover cluster configuration requires administrator privileges and these resources do not have a Credential parameter of their own and depend on PSDscRunAsCredential. Therefore, you need at least PowerShell 5.0 to use these resources.
I am looking at expanding the resource modules to beyond what is there at the moment. If you see any issues or have feedback, feel free to create an issue in my repository. These resources lack tests today. I would be glad to accept any PRs for tests.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.