As a Consultant

Working with msi files can be a challenge if you are not used to packaging applications and have access to tools that provide information about them. Then there comes a time when you need to do some automation with an MSI-package and you sure would like to have a tool to access 2 of the core properties of an msi; ProductCode and ProductName .  Here is something I have built and it is based upon the DSC resource Package that got updated in wave 3.  Sourcecode is on bitbucket: Cheers Tore

Update 12.10.2016 - More functions added to repro some while ago This module has been laying dormant in my BitBucket repro. Looks like people are realizing that DSC is about to become a thing. Need some feedback if this is a way of handling your Configuration data in DSC. I will publish it to the PowershellGallery if people find it useful. Should probably do a code review as well since this was written over 2 years ago :-0. Update 19.04.2014 - Module (beta) added to bitbucket here When you start to work with DSC, you quickly realize that separating the infrastructure from the configuration is a huge benefit and somewhat of a curse. You start to read blogs and webposts explaining how you can specify the configurationdata to you configuration, however for the people that does not speak powershell (yes they are out there) and/or still don’t like it, it looks kind of “untidy”. Example: Yes, Beelzebub has joined the party, pure evil. Just to explain ConfigurationData in Desired ...

Here we go again. This is just a short post on how to use the resource to join a computer to the domain. Steps we will perform: Download the resource from here . Follow the instructions to add it to the modules folder on you target computer. Create configuration data Build a very short configuration Here is the configuration data we will use: $ConfigData = @{ AllNodes = @( @{ NodeName = "*" PSDscAllowPlainTextPassword = $true } @{ NodeName = "localhost" } ); NonNodeData = @{           domainName = "try.local"       } } A few points to note here: We have a node called “*”. It is kind of a “wildcard”, however wildcards are not supported in DSC. All key/values you specify in this node, will get inherited by all nodes. That is why I do not need to specify the PSDscAllowPla...

Today we are doing 2 things, or actually 3 things: Building a custom Get-EvntLog function built upon the standard Get-WinEvent cmdlet Using DefaultDisplayProperties Using an embedded function in an function (why, because why not, we can?) Main reasons for doing this: Bug in .net and/or Get-WinEvent for any other culture than en-us (I use no-nb), The message property is returned as $null if I use Get-WinEvent Speed – Get-Eventlog is fine, however I want speed like we get with Get-WinEvent I can work around the bug in Get-WinEvent by temporarily switching to the culture en-us. When I have used Get-WinEvent and processed the results, I reset the culture to the original state. No harm done. A few words about the custom object function (Create-CustomObject). It takes 2 parameters; Properties ([string[]]) and DefaultDisplayProps([string[]]). At the end it spits out a new object (PSobject) with the DefaultDisplayPropertySet’ configured. To demonstrate: Okay, so ...