Monthly Archive

Categories

Monthly Archives: January 2015

Add-Computer is your friend

When spinning up new machines and joining them to the domain at least 2 reboots are required. One when you rename the machine (Windows used to let you specify the name at install time – the removal of that feature was a step backwards) and the other when you join it to the domain.

 

I was looking at the help file for Add-Computer and discovered you can rename the machine as you join it to the domain. Miss one reboot and get the build finished quicker.

$cred = Get-Credential manticore\richard
Add-Computer -Credential $cred -DomainName manticore -NewName W12R2Web02 -Restart –Force

 

Nice and simple – I like this.

foreach, pipelines and $_

I’ve recently seen a few questions where people have been using a pipeline inside a foreach loop and experienced problems when they’ve tried to access properties on the looping objects. To illustrate we’ll start with a CSV file containing emailaddresses and job titles.

£> Import-Csv -Path C:\Test\userdata.txt

emailaddress             title   
------------             -----   
gdreen@Manticore.org     Boss    
dbrown@Manticore.org     Underling
dwhite@Manticore.org     Underling
jdaven@Manticore.org     Minion  
fgreen@Manticore.org     Minion  
dgreensmth@Manticore.org Minion  
dgreenly@Manticore.org   Minion

This is definitely an employee friendly organisation Smile

At the moment AD doesn’t contain any job title information

£> $users = Import-Csv -Path C:\Test\userdata.txt

foreach ($user in $users){
$mail = $user.EmailAddress

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
select Name, Title

}

Name                                      Title                                  
----                                      -----                                  
Dave Green                                                                       
Dave Brown                                                                       
Dave White                                                                       
Jo Daven                                                                         
Fred Green                                                                       
Dale Greensmith                                                                  
Dave Greenly

 

The approach that causes problems is this:

£> $users = Import-Csv -Path C:\Test\userdata.txt

foreach ($user in $users){
$mail = $user.EmailAddress

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
foreach {Set-ADUser -Identity $_ -Title $_.Title} |

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
select Name, Title
}

Name                                      Title                                  
----                                      -----                                  
Dave Green                                                                       
Dave Brown                                                                       
Dave White                                                                       
Jo Daven                                                                         
Fred Green                                                                       
Dale Greensmith                                                                  
Dave Greenly     

 

When you use foreach as a keyword the $_ and $psitem variables aren’t available. These variables represent the current object on the pipeline.  The foreach keyword loop doesn’t have a pipeline as such.

 

Inside the foreach a pipeline is created

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
foreach {Set-ADUser -Identity $_ -Title $_.Title -PassThru} |
select Name, Title

 

$_ is used correctly to identify the object on which Set-ADUser is to work – its the current object on the pipeline.

 

The use of  $_.Title  to set the user’s job title is where the problem really bites.  $_.Title  refers to the Title property of the current object on the pipeline so you are setting the Title to its existing value.

 

You need to reach back to the $user object that represents the current object from the set you are looping through with foreach to get the correct value

£> $users = Import-Csv -Path C:\Test\userdata.txt

foreach ($user in $users){
$mail = $user.EmailAddress

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
foreach {Set-ADUser -Identity $_ -Title $user.Title} |

Get-ADUser -Filter {EmailAddress -eq $mail} -Properties Title |
select Name, Title
}

Name                                      Title                                  
----                                      -----                                  
Dave Green                                Boss                                   
Dave Brown                                Underling                              
Dave White                                Underling                              
Jo Daven                                  Minion                                 
Fred Green                                Minion                                 
Dale Greensmith                           Minion                                 
Dave Greenly                              Minion  

 

You’ll see similar problems if you have nested foreach-object loops or a switch statement inside a foreach-object loop.  $_ always refers to the current context and you have to either reach back to the looping variable in the csae of a foreach or set variables on the data in the outer foreach before entering the nested foreach.

DHCP scope lease time

I wanted to reduce the lease time on a DHCP scope

 

$lt = New-TimeSpan -Hours 12
Set-DhcpServerv4Scope -ScopeId 10.10.54.0 -LeaseDuration $lt

 

You could even make it a one liner if you wished

 

Set-DhcpServerv4Scope -ScopeId 10.10.54.0 –LeaseDuration (New-TimeSpan -Hours 12)

A use for default parameters – default powershellget repository

When you use Find-Module by default all repositories are searched

£> Find-Module -Name Pester | ft Version, Name, Repository -a

Version Name   Repository
------- ----   ----------
3.2.0   Pester PSGallery
3.2.0   Pester PowerShellModules

 

If you don’t give a module name that could be a lot of data to sort through. If you are running an internal repository you may want to check that repository first and only use other repositories if that one doesn’t contain the module.

 

£> Find-Module -Name Pester -Repository PowerShellModules  | ft Version, Name, Repository -a

Version Name   Repository
------- ----   ----------
3.2.0   Pester PowerShellModules

 

This means that you have to type the repository name each time. It would be better if you could make a particular repository the default.  One way to do this is to define default parameters. This functionality was introduced in PowerShell 3.0

 

£> $PSDefaultParameterValues.Add("Find-Module:Repository", 'PowerShellModules')

£> $PSDefaultParameterValues

Name                           Value
----                           -----
Find-Module:Repository         PowerShellModules

£> Find-Module -Name Pester | ft Version, Name, Repository -a

Version Name   Repository
------- ----   ----------
3.2.0   Pester PowerShellModules

 

You can override the default if you wish

£> Find-Module -Name Pester -Repository PSGallery  | ft Version, Name, Repository -a

Version Name   Repository
------- ----   ----------
3.2.0   Pester PSGallery

 

You can do the same for install-module so that it will default to your internal repository

£> $PSDefaultParameterValues.Add("Install-Module:Repository", 'PowerShellModules')

£> Install-Module -Name Pester -Force -Verbose
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Using the specified source names : 'PowerShellModules'.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'http://localhost:81/nuget/PowerShellModules' and OneGetProvider is 'NuGet'.
VERBOSE: In PSModule Provider - 'Get-InstalledPackage'.
VERBOSE: The specified Location is 'NuGet' and OneGetProvider is 'NuGet'.
VERBOSE: Downloading module 'Pester' with version '3.2.0' from the repository
'http://localhost:81/nuget/PowerShellModules'.
VERBOSE: NuGet: Installing 'Pester 3.2.0'.
VERBOSE: NuGet: Successfully installed 'Pester 3.2.0'.
VERBOSE: Module 'Pester' was installed successfully.

 

-Force was used as the module is already installed.

 

Your default parameters now look like this

£> $PSDefaultParameterValues

Name                           Value
----                           -----
Find-Module:Repository         PowerShellModules
Install-Module:Repository      PowerShellModules

 

Add the two lines

$PSDefaultParameterValues.Add("Find-Module:Repository", 'PowerShellModules')

$PSDefaultParameterValues.Add("Install-Module:Repository", 'PowerShellModules')

 

To your profile and your defaults will be available every time you start PowerShell

PowerShell Summit Europe 2015–topic submissions

Topic submissions for the PowerShell Summit Europe are still open. If you want to be considered as a speaker please submit your topic very soon.

 

At the moment there aren’t enough submissions to enable us to put on a quality event. The 2014 European Summit was an excellent event with many good sessions – now is the time to submit your sessions. We need your sessions.

 

We have a policy of accepting sessions from new speakers as well as established experts. It’s not who you are but the quality of the session that counts.

 

Details on how to submit session proposals are available here

http://powershell.org/wp/2014/11/24/call-for-presentations-for-powershell-summit-europe-2015/

 

Please submit your proposals soon as we can’t run the European PowerShell Summit without them

Accessing your PowerShellget repository from another machine

So far the new PowerShellGet repository has been accessed from the local machine. You need to register the new repository on each machine from which you want to access it.

Register-PSRepository -Name PowerShellModules -SourceLocation http://W12R2DSC:81/nuget/PowerShellModules -InstallationPolicy Trusted

 

The only change to is substituting the name of the server for localhost in the source location URI.

 

NOTE: you will need to ensure that the Windows firewall is either off or allows the appropriate traffic through to the server hosting you repository

 

You can use the new repository

PS C:\Windows\system32> Get-PSRepository | ft Name, SourceLocation -AutoSize

Name              SourceLocation
----              --------------
PSGallery         https://www.powershellgallery.com/api/v2/
MSPSGallery       http://search.microsoft.com/default.aspx
PowerShellModules http://w12r2dsc:81/nuget/PowerShellModules

 

And see the modules

PS C:\Windows\system32> Find-Module -Name Pester | ft -a

Version Name   Repository        Description
------- ----   ----------        -----------
3.2.0   Pester PSGallery         Pester provides a framework
3.2.0   Pester PowerShellModules Pester provides a framework

 

And install modules

PS C:\Windows\system32> Install-Module -Name pester -Repository PowerShellModules

 

PS C:\Windows\system32> Get-Module -ListAvailable pest* | ft -a

    Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version Name   ExportedCommands
---------- ------- ----   ----------------
Script     3.2.0   Pester {Describe, Context, It, Should...}

Working with multiple PowerShellGet repositories

In http://blogs.msmvps.com/richardsiddaway/2015/01/04/creating-a-powershellget-repository/  I showed how to create a repository to use with PowerShellGet.  At the end of that article PowerShellGet would search all of the defined repositories for a module

£> Find-Module -Name Pester | Format-Table Version, Name, Repository -AutoSize

Version Name   Repository
------- ----   ----------
3.2.0   Pester PSGallery
3.2.0   Pester PowerShellModules

 

If you delete the Pester module and want to re-install it you need to specify the repository otherwise you get an error:

£> Install-Module -Name Pester -Verbose
VERBOSE: The -Repository parameter was not specified.  PowerShellGet will use all of the registered repositories.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'https://www.powershellgallery.com/api/v2/' and OneGetProvider is 'NuGet'.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'http://search.microsoft.com/default.aspx' and OneGetProvider is 'NuGet'.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'http://localhost:81/nuget/PowerShellModules' and OneGetProvider is 'NuGet'.
WARNING: 'Pester' matched module 'Pester/3.2.0' from provider: 'PSModule', repository
'https://www.powershellgallery.com/api/v2/'
WARNING: 'Pester' matched module 'Pester/3.2.0' from provider: 'PSModule', repository
'http://localhost:81/nuget/PowerShellModules'
OneGet\Install-Package : Unable to install, multiple modules matched 'Pester'. Please specify a single -Repository.
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PowerShellGet\PSGet.psm1:615 char:21
+             $null = OneGet\Install-Package @PSBoundParameters
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], E
   xception
    + FullyQualifiedErrorId : DisambiguateForInstall,Microsoft.PowerShell.OneGet.CmdLets.InstallPackage

 

£> Install-Module -Name Pester -Repository PowerShellModules -Verbose
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Using the specified source names : 'PowerShellModules'.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'http://localhost:81/nuget/PowerShellModules' and OneGetProvider is 'NuGet'.
VERBOSE: In PSModule Provider - 'Get-InstalledPackage'.
VERBOSE: Performing the operation "Install-Module" on target "Version '3.2.0' of module 'Pester'".
VERBOSE: The specified Location is 'NuGet' and OneGetProvider is 'NuGet'.
VERBOSE: Downloading module 'Pester' with version '3.2.0' from the repository
'http://localhost:81/nuget/PowerShellModules'.
VERBOSE: NuGet: Installing 'Pester 3.2.0'.
VERBOSE: NuGet: Successfully installed 'Pester 3.2.0'.
VERBOSE: Module 'Pester' was installed successfully.

Creating a PowerShellGet repository

In this post - http://blogs.msmvps.com/richardsiddaway/2014/12/21/delivering-powershell-code-with-the-november-preview/ – I showed how to use PowerShellGet, which is a feature new to PowerShell 5.0 to install PowerShell modules. By default PowerShelget uses the PowerShell gallery at https://www.powershellgallery.com as its source.

 

I don’t feel comfortable installing modules direct from a public gallery so I want my own.  I suspect that many organizations will want to use their own module repository rather than something on the Internet over which they have no control.

 

There are a number of options for setting up your own gallery.

You could create an online nuget feed. This is described in this post from the PowerShell team:
http://blogs.msdn.com/b/powershell/archive/2014/05/20/setting-up-an-internal-powershellget-repository.aspx

 

You could create your own nuget repository – an example of doing this can be found here - http://learn-powershell.net/2014/04/11/setting-up-a-nuget-feed-for-use-with-oneget/

 

After reading http://asaconsultant.blogspot.no/2014/05/build-your-local-powershell- module.html I decided to start with ProGet (http://inedo.com/proget/pricing) as it seemed simple and was installed locally so I could take it with me to do demos.

 

To keep things even simpler I went with the free version and used the download that also  installs SQL Express. The installer also can create a service INEDOPROGETSVC to host the web service ProGet will use. Set the Service to use the LocalSystem account so that it can access the location to which the modules will be published.

 

The ProGet default feed is nuget but you want your own for this game.  Its not obvious how to do this but open Proget administration page - http://localhost:81/administration

 

I’m using port 81 as this is running on my DSC server.

 

Click manage feeds and you’ll find a button labelled Create New Feed. Press the button.

You have 3 choices

A nuget feed

A chocolately feed

a npm feed (private registry)

Lets go with nuget.

 

After supplying a name and description I went with the defaults to complete the feed creation.

 

At this point PowerShellget can’t see the new repository so you need to register it.

£> Register-PSRepository -Name PowerShellModules -SourceLocation http://localhost:81/nuget/PowerShellModules -Installati
onPolicy Trusted

 

And it now shows in my list of PowerShell repositories

£> Get-PSRepository | fl Name, SourceLocation

Name           : PSGallery
SourceLocation : https://www.powershellgallery.com/api/v2/

Name           : MSPSGallery
SourceLocation : http://search.microsoft.com/default.aspx

Name           : PowerShellModules
SourceLocation : http://localhost:81/nuget/PowerShellModules

 

You need to set a location to which modules will be published

Set-PSRepository -Name PowerShellModules -PublishLocation 'http://localhost:81/nuget/PowerShellModules'

 

Now to try and publish a module.

 

I’m going to use the Pester module I downloaded in the previous article:

 

£> Publish-Module -Name Pester -NuGetApiKey "Admin:Admin" -Repository PowerShellModules -Verbose
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Module'Pester' was found in 'C:\Program Files\WindowsPowerShell\Modules\Pester'.
VERBOSE: Loading module from path 'C:\Users\Richard\AppData\Local\Temp\409922302\Pester\Pester.psm1'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Repository details, Name = 'PowerShellModules', Location = 'http://localhost:81/nuget/PowerShellModules';
IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Using the specified source names : 'PowerShellModules'.
VERBOSE: Getting the provider object for the OneGet Provider 'NuGet'.
VERBOSE: The specified Location is 'http://localhost:81/nuget/PowerShellModules' and OneGetProvider is 'NuGet'.
VERBOSE: Performing the operation "Publish-Module" on target "Version '3.2.0' of module 'Pester'".
VERBOSE: Successfully published module 'Pester' to the module publish location
'http://localhost:81/nuget/PowerShellModules'.

 

The -NuGetApiKey "Admin:Admin"  is the default and you’d want to change that for a production system.

 

Finally test the repository contents

£> Find-Module -Repository PowerShellModules

Version    Name                                Repository
-------    ----                                ----------
3.2.0      Pester                              PowerShellModules

PowerShell in 2015

See Don Jones’ predictions for PowerShell in 2015 - http://blogs.technet.com/b/heyscriptingguy/archive/2015/01/01/powershell-predictions-for-2015.aspx