DexterPOSH's Blog

Recently, I have been writing/ reading a lot of Pester tests (both Unit and Integration) for infrastructure validation. One of the classic limitation hit during mocking with Pester is that you can have different mocks based on different arguments to a parameter (e.g using parameterFilter with Mock ) but not based on a counter. For Example - See below, I have two mocks for Get-Process cmdlet based on the name passed to it. Mock   -CommandName   Get-Service  -ParameterFilter   { $Name   -eq   'winrm' }   -mockwith   {[PSCustomObjet]@{Status='Running'} } Mock   -CommandName   Get-Service   -ParameterFilter   { $Name   -eq   'bits' }   -mockwith   { [PSCustomObjet]@{Status='Stopped' } This is really helpful, but there is a case where we want different mocks to occur based on a an incremental counter (number of times) a function/Cmdlet etc. are called in our script.

If you are authoring scripts targeting Nano server specifically then there are two checks which you can bake into (maybe add them to the default nano authoring snippet in ISE) them.

Do you remember ? In the older Azure Service Management model, we had an option to import the publish settings file and use the certificate for authenticating. It saved a lot of hassle. That method is deprecating now but we have something better which we can use in the newer ARM model. BTW for record I find it really annoying to enter credentials each time when I want to quickly try something out on Azure. So I have been using two techniques for automated login to the AzureRM portal. Storing Service principal creds locally (encrypted at rest using Windows Data Protection API) and using that to login. Using Certificate based automated login .