Part of an inventory I did for a customer were some defaults of their IIS configuration.
Here’s a oneliner to get the default log directory from IIS:
(Get-WebConfigurationProperty '/system.applicationHost/sites/siteDefaults' -Name 'logfile.directory').Value
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