Last week I met up with Bert Wolters for a video presentation/interview. Bert has been recording a series of sessions on the latest and greatest functionality in Windows 10 and in this episode I discuss some of the new functionalities in PowerShell 5.0 in combination with Windows 10. The video has been recorded in Dutch, so unfortunately it will a bit hard to follow for the English speaking community.
In the video I showcase the following features:
- Better Multiline support for the PowerShell console
- Colored console for cmdlets, parameters and arguments
- PowerShell cmdlets for Windows Defender
- PowerShell debugging in the ISE using <CTRL> + B
- DuPSUG, Dutch PowerShell User Group
For more information or the direct link of the video in this article please refer to the links below. Feel free to leave a comment either here or in the YouTube comment section.
|Links in the article|
|Experts Live TV – 10 weken Windows 10 – Aflevering 9 – Powershell 5|
|DuPSUG.com, Dutch PowerShell User Group|
Last week I was helping a fellow IT Pro at a customer troubleshooting an Windows Azure Pack DSC resource.
We were getting errors we could not explain, but when running the code manually from our ISE everything went alright.
Eventually we pinned it down to a section of the code where we needed to get a True back, when instead we got a False.
There was one thing in our troubleshooting that triggered me…
When executing it through DSC, it failed.
When executing it by hand, it succeeded.
If you execute it via DSC, it runs in a system context.
Sure, you can define credentials, but there is no option for user interaction the moment the code hits the client.
So my guess was that there seemed to be something in the Azure DSC resource that required user interaction… and we started looking.
We didn’t find anything that required user interaction.
But there was something else. We used the DSC resources before… when installing all of the WAP roles on a single server.
And we had no issues with that. None at all!
So… what does not require user input, but works under a user context and doesn’t under a system context? …and has in any way a correlation between having all roles installed on a single server or spreading them out over multiple servers?
As we found out, the Invoke-Command cmdlet was used all over the Azure DSC resources!
… and not to connect to remote devices, simply to execute code on the local machine.
After changing the code of the DSC resource and removing all the Invoke-Command entries in there, it worked like a charm!
Invoke-Command in a DSC Resource
First: Invoke-Command basically is build on top of PowerShell Remoting. If you don’t need it, don’t use it. There are other ways of executing code locally
In my personal opinion, there is no reason to use Invoke-Command in a DSC resource.
Second: If you need to execute code on a different machine than the one running the DSC configuration, use a different DSC configuration for that other machine!
You can use WaitFor* DSC resources for inter-node dependency and such
Didn’t the author test this?
I guess he/she did. We only discovered this issue when we wanted to install Windows Azure Pack roles on separate servers instead of installing all of them on one server.
So when the author tested the resource, all roles were probably installed on a single server and no issue would appear
In PowerShell, each script has its own scope. Anything defined in that script, for example variables and functions, exists only within that scope.
You can’t access those items from the scope where the script is run… only from within the script.
So a function inside the script can call another function inside the script, but you can’t call a function defined in the script from the scope where you run/call the script.
Let that one sink in a little
So what if you want to make something available in your current scope, that is defined within a script.
Normally I would tell people to write a module, but in the case of a customer I was at last week they needed to manage servers where they were not allowed to place a module.
This is an ongoing discussion, but for now we needed to make things work.
I like re-usable code… I like it a lot.
So creating many scripts with the same functions, and just a little bit of code that differs, would have been madness… or at least, that’s my opinion.
This is where dot sourcing helps out
Let’s say that you have a script where you define a whole bunch of variables and/or functions that you want to make available in your current scope.
Call a script like so:
So, simply but a dot in front of the script You’ll notice that the things defined in that script, will now be available in your current scope.
Neat little trick, right?!