Powershell: how to return value from function?

Returning a value from a function is really easy in Powershell. Sometimes it is too easy if you are not careful about it. One important detail to keep in mind is that Powershell is built around placing objects on the pipe. This makes functions work differently in Powershell than it does from different languages. You are also not limited to just one return value.

Here is a minimal function:

function Test-Function

{

    "Hello World!"

} 

Calling this places a string of "Hello World!" onto the pipe. You can catch it in a variable if you want or pipe it to some other command. The better way to do it is to use the Write-Output cmdlet. It makes it more clear as to what you are doing do debugging and troubleshooting become easier. 

function Test-Function

{

    Write-Output "Hello World!"

}

You can call Write-Output multiple times in a function to return multiple items. You could place it into a loop that runs 10 times and it will output 10 objects. I mention this because Powershell also supports the return keyword but it acts different. When a function gets to any return statement, it exits the function. 

function Test-Function

{

    return "Hello World!"

}

I prefer Write-Output over return but do use return when it is needed. 

I also want to mention that Write-Host is something that you see in scripts from time to time, but it is for host only output. So it is hard to capture into a variable and does not go into the pipe. In most cases, Write-Output is the better choice.

Powershell: how to call a function?

Sometimes it is the simplest thing that can be the most frustrating when learning a new language. Calling a custom function in Powershell can be one of those if you come from a different language. If you are having an issue with this, you have come to the right place. You are probably looking at something like this and wondering why it wont work:

TestFunction($Name, $Count)

If your coming from another language, this looks like it would be perfectly normal. The gotcha in Powershell is that the coma and the parenthesis are not needed here for a function call and actually mean something else. In this example it defines an array.

  

Before I go any further, let's define TestFunction:

function TestFunction ($name, $count)

{

    Write-Output "Name is '$name' and Count is '$count'"

}

It is a simple function that takes two parameters. While this works as a function and looks like something you know, let's do it the Powershell way:

function TestFunction

{

    param($name, $count)

    Write-Output "Name is '$name' and Count is '$count'"

}

So now we have a function that takes two arguments. The first argument is name and the second argument is count. Here are the correct ways to call that function:

TestFunction $Name $Count

TestFunction -name $Name -count $Count

TestFunction -name "Kevin" -count 1 

Now that we know the correct way to make that call and know what the function looks like, I can explain why our initial call fails to work. Because it is the equivalent to this call:

$Array = ($Name,$Count)

TestFunction -name $Array -count $null

So you were basically creating an array that contained your two variables and passing it in as an array to the first argument. You were also leaving the second argument as a null value. Now that you see it, it looks like a silly thing to do. No wonder things were not working as you expected. 

Powershell: how to concatenate strings?

I was going to write a post on how to concatenate or join string, but the Hey, Scripting Guy! Blog already has a great write up on that.

Quick and Dirty Powershell Modules

So you have built some awesome scripts and turned them into advanced functions. Whats next? It is time to put them into a module. It can be a lot easier than you realize. Lets go step by step and build our first module to hold all of your advanced functions.

# Start in our profile powershell folder

CD ~\Documents\WindowsPowershell

# Create a folder for our module and functions

MD Modules\Other\Functions

# Create a module manifest

$Manifest = @{

    Path        = ".\Modules\Other\Other.psd1"

    RootModule  = ".\Other.psm1" # Module loader

    Author      = "Kevin Marquette"

    Description = "Odds and ends"   

}

New-ModuleManifest @Manifest -Verbose

# Create our module loader (that loads our advanced functions)

$ModuleLoader = @'

  $moduleRoot = Split-Path -Path $MyInvocation.MyCommand.Path

  Write-Verbose "Importing Functions"

  # Import everything in the functions folder

  "$moduleRoot\Functions\*.ps1" |

      Resolve-Path |

      Where-Object { -not ($_.ProviderPath.Contains(".Tests.")) } |

      ForEach-Object { . $_.ProviderPath ; Write-Verbose $_.ProviderPath}

'@

Set-Content -Value $ModuleLoader -Path .\Modules\Other\Other.psm1

# Now create a single file for each advanced function and place it in the functions folder

# Sample function

$TestFunction = @'

   function Test-Other

   {

        [cmdletbinding()]

        param()

        Write-Output "Hello World!!"

   }

'@

Set-Content -Value $TestFunction -Path .\Modules\Other\functions\Test-Other.ps1

# Load it and test it out

Import-Module Other -Verbose -Force

Test-Other

You could easily place all your functions into the Other.psm1 file and everything would still work. But this creates a framework that makes your functions easy to manage. That functions folder can now be a dumping ground for all your advanced functions. If you out grow this module, you can create a new one and just move the functions over.

The module loader is what enables that. Later we will add pester tests and this already accounts for this. This is a pattern that I seen used by other Powershell MVPs. It has greatly simplified my function management.

JoinDomainOrWorkgroup 1323 error unable to update the password

I am using the Win32_ComputerSystem WMI object to join machines to a domain with JoinDomainOrWorkgroup. Then I ran into an issue on XP/2003 where I would get this 1323 return code and it would fail. This looked to work find for server 2012 so I started digging.

From the MSDN documentation, error 1323 means  "error unable to update the password".  My first set of searches implied that the time was out of sync between the servers. Manual join worked fine and after syncing the time to the DC before the join, I had the same issue.

$wmi.JoinDomainOrWorkgroup("Domain","Password","UserName",$null,3) 

Then I found a comment here that said add the domain to the username.

$wmi.JoinDomainOrWorkgroup("Domain","Password","Domain\UserName",$null,3) 

And then it worked.

Solving the hardest problems with powershell. Where to go next?

Sometimes you run into a problem and you don’t know where to go next. When I run into an issue, it often becomes an obsession for me to solve it. It is easy to say google it, but sometimes you need to be able to look at your problem from different points of view for google to actually help you. I have been wiring Powershell for a long time and this is how I tackle those hard to solve problems.

First use get-help, get-command, show-command, get-member, and Format-List * to try and discover a command and get information about object. The more advanced you get with Powershell, the more you will use these commands. So build that habit. (Run update-help to get the most recent updates).

Then turn to google. Something like “Powershell thing I am trying to do”. There are a lot of good samples and old samples out there. The old samples will still work but you may miss the new way to solve that problem if you are on server 2012/windows 8. This is why those first commands are important. If you want examples, get-help command –examples.

Then search for a command line way to do it. If a command or a tool exists, then that’s the easiest way. Depending on what I find, I may look at other solutions and come back to this one.

If this is a standalone application, figure out how it stores its settings. Registry, text file or database. Knowing this will give you a direction. I’ll mention how to flesh these out later if you are unsure at this point.

Then search for a WMI solution. Powershell and WMI play really well together. Windows is an API based OS and a lot of those APIs are exposed in WMI or CIM. People have been working with WMI for a long time and lots of examples exists. I solve a lot of problems with WMI. One I know the object to look at, get-member and format-list * help me explore it. There is also a show-object script floating around that may also help here.

Then google for how to solve your problem with the registry. The registry really controls a lot of things and I would bet a lot of the Powershell script for system configuration are just setting a value in the registry if it is not using WMI.

From here, I look for a VBScript or C#/.Net solution. If it feels like something an admin should be able to do, I will search harder for VBscript. Odds are that someone has solved this issue before. VBScript is easy to translate into simpler Powershell once you have done it a few times. C# and .Net offer a lot of power but you may be diving into some serious code at this point. You can take this to an extreme and look for Win32 API or system calls (rundll32 type stuff). This is never fun but sometimes that is where the solution is.

Another approach is using sysinternals to figure out how the system does what it is doing. Procmon is great. It watches every file change and registry change that your system does. So fire that up, and make your change. Then start hunting for what the system did when you make that change. If SQL is involved, then SQL profiler is also a must have tool.

Look for a GPO solution. If you can find one, remember that most of group policy is just setting registry keys. If there is an ADM file, you can dig into that for the actual key.

While you are doing your hunting, there are a few complications to be aware of. Is it a per user setting or a per machine setting. User profiles can easily be adjusted by the user, but if you are remote or running with different creds, there are often other roadblocks to deal with.

Also, there is nothing wrong with asking for help either. I just wanted to give you a direction. Even if this is all gibberish today. The more advanced you get at this, the deeper down the rabbit hole you can go. I have used every one of these techniques at some point to solve a problem.

Using Pester to validate DSC resources and configurations Part 2

Pester tests are like any other script. They grow and evolve over time. Here are a few more tests that I have testing my DSC resources and configurations that I recently added to my collection. 

Does every resource have a pester test?

This is probably one of the most important tests I have. Every resource should have a test, so why not test for that?

describe "DSCResources located in $PSScriptRoot\DSCResources" {

  foreach($Resource in $ResourceList)

  {

    context $Resource.name {

      it "Has a pester test" {

        ($Resource.fullname + "\*.test.ps1") | should exist

      }

If it is a standard resource, does it have the files it needs?

Each DSC resource needs to have two files in it. A *.psm1 file and a *.schema.mof file. I use the *.psm1 file as a quick way to identify standard resources differently than a composite resource. I know I will not ever reach a test condition that would cause once of these to fail, but I left it in place so I could change the logic later.

if(Test-Path ($Resource.fullname + "\$Resource.psm1"))

{

  it "Has a $Resource.schema.mof" {

                     

    ($Resource.fullname + "\$Resource.schema.mof") | should exist

  }

 

  it "Has a $Resource.psm1" {

                     

    ($Resource.fullname + "\$Resource.psm1") | should exist

  }

Does it pass Test-xDscSchema and Test-xDscResource tests?

I may as well test for these as part of my pester tests. They already validate a lot of things that are easy to overlook.

it "Passes Test-xDscSchema *.schema.mof" {

  Test-xDscSchema ($Resource.fullname + "\$Resource.schema.mof") | should be true

}

 

it "Passes Test-xDscResource" {

  Test-xDscResource $Resource.fullname | should be true

}

If it is a composite resource, does it have the required files?

A composite resource uses different files than a standard resource. It has a *.psd1 and a *.shema.psm1 that should exists. I don’t have any Test-xDSC functions for the composite resources so I add a few extra checks. I verify that the *.psd1 file references the *.psm1 and that the module does not throw any errors when dot sourcing it.

else

{

  it "Has a $Resource.schema.psm1" {

                     

    ($Resource.fullname + "\$Resource.schema.psm1") | should exist

  }

 

  it "Has a $Resource.psd1" {

                     

    ($Resource.fullname + "\$Resource.psd1") | should exist

  }

 

  it "Has a psd1 that loads the schema.psm1" {

 

    ($Resource.fullname + "\$Resource.psd1") | should contain "$Resource.schema.psm1"

  }

 

  it "dot-sourcing should not throw an error" {

 

    $path = ($Resource.fullname + "\$Resource.schema.psm1")

    { Invoke-expression (Get-Content $path -raw) } | should not throw

  }

I hope you find this examples useful. If you want to see more, take a look at part 1.