PowerShell 2.0: One Cmdlet at a Time #74 Test-ModuleManifest

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Test-ModuleManifest cmdlet.

What can I do with it?

PowerShell 2.0 introduces the concept of modules; essentially they are the evolution of snapins from PowerShell 1.0.  A module creator could use Test-Module to ensure that files listed in a *.psd1 file, possibly created by New-ModuleManifest , are valid.

Example:

Test that the C:\Users\User1\Documents\WindowsPowerShell\Modules\Logfile-Module\Logfile-Module.psd1 (created in the New-ModuleManifest example) is valid.

Test-ModuleManifest -Path 
'C:\Users\User1\Documents\WindowsPowerShell\Modules\Logfile-Module\Logfile-Module.psd1'

You will see that this returns an object for the module. If any files were not valid then an error message would be produced.

To obtain a tidy True or False answer the ErrorAction parameter can be used with the Silently Continue value to surpress any errors. By then examining the current value of the $? automatic variable such an answer can be obtained.

Test-ModuleManifest -Path 
'C:\Users\User1\Documents\WindowsPowerShell\Modules\Logfile-Module\Logfile-Module.psd1' 
-ErrorAction SilentlyContinue
$?

You will see the result in this case is True.

How could I have done this in PowerShell 1.0?

This functionality was not avaliable with snapins in PowerShell 1.0

1000 things 1% better

PowerShell 2.0: One Cmdlet at a Time #73 New-ModuleManifest

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the New-ModuleManifest cmdlet.

What can I do with it?

PowerShell 2.0 introduces the concept of modules; essentially they are the evolution of snapins from PowerShell 1.0. Creators of Modules can use the New-ModuleManifest cmdlet to create a module manifest *.psd1 file which can be used to enhance to processes around a module, such as any prerequisites. Note: More info about writing a module manifest can be found here.

Example:

Create a new module manifest file using a mixture of default and specified values.

New-ModuleManifest

You will see that you are prompted to enter values to put in the manifest file and those which have defaults.

The *.psd1 file is created in the standard module location C:\Users\Username\Documents\WindowsPowerShell\Modules\ alongside the *.psm1 containing the module.

The contents of the *.psd1 file will look like the below:

#
# Module manifest for module 'Logfile-Module'
#
# Generated by: Jonathan Medd
#
# Generated on: 10/03/2010
#

@{

# Script module or binary module file associated with this manifest
ModuleToProcess = 'Logile-Module.psm1'

# Version number of this module.
ModuleVersion = '1.0'

# ID used to uniquely identify this module
GUID = '876e3d17-66ac-40f6-9e10-09913679011a'

# Author of this module
Author = 'Jonathan Medd'

# Company or vendor of this module
CompanyName = 'Medd Enterprises'

# Copyright statement for this module
Copyright = 'Copyright © 2010 Jonathan Medd. All rights reserved.'

# Description of the functionality provided by this module
Description = 'Logfile Functions'

# Minimum version of the Windows PowerShell engine required by this module
PowerShellVersion = ''

# Name of the Windows PowerShell host required by this module
PowerShellHostName = ''

# Minimum version of the Windows PowerShell host required by this module
PowerShellHostVersion = ''

# Minimum version of the .NET Framework required by this module
DotNetFrameworkVersion = ''

# Minimum version of the common language runtime (CLR) required by this module
CLRVersion = ''

# Processor architecture (None, X86, Amd64, IA64) required by this module
ProcessorArchitecture = ''

# Modules that must be imported into the global environment prior to importing this module
RequiredModules = @()

# Assemblies that must be loaded prior to importing this module
RequiredAssemblies = @()

# Script files (.ps1) that are run in the caller's environment prior to importing this module
ScriptsToProcess = @()

# Type files (.ps1xml) to be loaded when importing this module
TypesToProcess = @()

# Format files (.ps1xml) to be loaded when importing this module
FormatsToProcess = @()

# Modules to import as nested modules of the module specified in ModuleToProcess
NestedModules = @()

# Functions to export from this module
FunctionsToExport = '*'

# Cmdlets to export from this module
CmdletsToExport = '*'

# Variables to export from this module
VariablesToExport = '*'

# Aliases to export from this module
AliasesToExport = '*'

# List of all modules packaged with this module
ModuleList = @()

# List of all files packaged with this module
FileList = 'Logfile-Module.psd1', 'Logfile-Module.psm1'

# Private data to pass to the module specified in ModuleToProcess
PrivateData = ''

}

How could I have done this in PowerShell 1.0?

This functionality was not avaliable with snapins in PowerShell 1.0

1000 things 1% better

PowerShell 2.0: One Cmdlet at a Time #72 Export-ModuleMember

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Export-ModuleMember cmdlet.

What can I do with it?

PowerShell 2.0 introduces the concept of modules; essentially they are the evolution of snapins from PowerShell 1.0. Export-ModuleMember specifies elements from a module, like functions or variables, which can be exported. Note: This cmdlet can only be used within a *.psm1 script module file or a dynamic module created with New-Module.

Examples:

Create a new dynamic module using New-Module containing two variables inside the scriptblock. Export only the variable $s2 so that it is available for use. Note: Export-ModuleMember needs to be included inside the scriptblock.

New-Module -ScriptBlock {$s1 = 'Server1'; $s2 = 'Server2';
 Export-ModuleMember -Variable s2}

You will notice that $s1 is not available in the current session, but $s2 is.

The other area to use this cmdlet is within a *.psm1 script module file.  In the below example by default all functions would be exported if the Export-ModuleMember cmdlet was not used. However, by using the Export-ModuleMember cmdlet we can control which functions are exported and also export aliases.

So in the example below the Write-Logfile and Greet-User functions would be exported, but the Yesterdays-Date function would not. In addition the gu alias would be exported.

How could I have done this in PowerShell 1.0?

This functionality was not avaliable with snapins in PowerShell 1.0

1000 things 1% better

PowerShell 2.0: One Cmdlet at a Time #71 New-Module

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the New-Module cmdlet.

What can I do with it?

PowerShell 2.0 introduces the concept of modules; essentially they are the evolution of snapins from PowerShell 1.0. New-Module enables you to create a dynamic module from a script block that is available in the current session.

Note: New-Module does not create a module on disk available for use at a later date! However, Jeffrey Snover has created a module which will create a template for a new module on disk for you.

Examples:

Create a new dynamic module with the Function Write-Logfile as the scriptblock to create the module. Test to see whether the function is available from Get-Module or Get-Command.

New-Module -ScriptBlock
{Function Write-Logfile ($log) {$Logfile = "C:\Log.txt"; $log
| Out-File -FilePath $Logfile -Append}}
Get-Module
Get-Command Write-Logfile

You will see that Get-Module is not aware of the new module, but Get-Command is aware of the Write-Logfile function.

Create a new dynamic module with the Function Write-Logfile as the scriptblock to create the module. Give it a name and use Import-Module to make it available to Get-Module.   Test to see whether the function is available from Get-Module or Get-Command.

New-Module -ScriptBlock
{Function Write-Logfile ($log) {$Logfile = "C:\Log.txt"; $log
| Out-File -FilePath $Logfile -Append}} -Name LogfileModule
| Import-Module
Get-Module
Get-Command Write-Logfile

You will see that this time both Get-Module and Get-Command are aware of the LogfileModule and Write-Logfile function.

How could I have done this in PowerShell 1.0?

You could have created a custom snapin and imported with the Add-PSSnapin cmdlet.

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #70 Import-Module

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Import-Module cmdlet.

What can I do with it?

PowerShell 2.0 introduces the concept of modules; essentially they are the evolution of snapins from PowerShell 1.0. Import-Module enables you to add one or more modules to your current session.

Examples:

Import the PSDiagnostics module and examine the newly available commands in the session from that module by using Get-Module.

Import-Module PSDiagnostics
Get-Command -Module PSDiagnostics

You will see there are ten new functions available from that module.

Import only two functions, Start-Trace and Stop-Trace from the PSDiagnostics module and examine the newly available commands in the session from that module by using Get-Module.

Import-Module PSDiagnostics -Function Start-Trace,Stop-Trace
Get-Command -Module PSDiagnostics

You will see that this time only those two functions are available.

How could I have done this in PowerShell 1.0?

You could have used the Add-PSSnapin cmdlet to import custom snapins typically produced by third-parties. For example to import the popular Quest AD cmdlets snapin you would use the below:

Add-PSSnapin Quest.ActiveRoles.ADManagement

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #69 Get-WinEvent

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Get-WinEvent cmdlet.

What can I do with it?

Retrieve items from Event Logs including event logs generated by the Windows Event Log technology, new since Windows Vista / 2008 Server, in addition to the classic System, Security and Application Logs. Note: it requires .NET Framework 3.5 or later installed.

Examples:

Retrieve events from the Setup Event Log.

Get-WinEvent -LogName Setup

You’ll see the typical information you would normally view in Event Viewer.

Get-WinEvent includes a -FilterHashTable parameter which allows you to filter results at source rather than pulling back all the events and then piping them through to Where-Object to perform filtering, so much more effiicient.

Retrieve events from the System Event Log only where the Event ID is 10148.

Get-WinEvent -FilterHashtable @{Logname='System';ID=10148}

You will see that only the events with ID 10148 are returned.

How could I have done this in PowerShell 1.0?

You could have used the Get-EventLog cmdlet, however it is not able to retrieve information from event logs generated by the Windows Event Log technology such as the Setup log mentioned in the above examples.

Get-EventLog -LogName System | Where-Object {$_.EventID -eq 10148}

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #68 Show-EventLog

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Show-EventLog cmdlet.

What can I do with it?

Open Event Viewer on a local or remote computer.

Example:

Open Event Viewer on the remote computer Test01.

Show-EventLog -ComputerName Test01

You will see that Event Viewer on the remote computer Test01 opens on the local machine.

How could I have done this in PowerShell 1.0?

You could have typed the executable Eventvwr to open Event Viewer on a local computer. To view it on the remote computer Test01 use:

eventvwr \\Test01

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #67 Remove-EventLog

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Remove-EventLog cmdlet.

What can I do with it?

Remove an Event Log.

Example:

Remove the Event Log named App1 on the remote computer Test01. Confirm it has been removed with Get-EventLog.

Remove-EventLog -LogName App1 -ComputerName Test01
Get-EventLog -List -ComputerName Test01

Confirmation that the App1 Event Log has been removed.

Note: To perform this task remotely you will need to ensure that Remote Event Log Management has been added as an Exception in Windows Firewall.

How could I have done this in PowerShell 1.0?

You could have have used the .NET System.Diagnostics.Eventlog class and the Delete method to delete an event log.

[system.diagnostics.eventlog]::Delete("App1")

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #66 Limit-EventLog

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Limit-EventLog cmdlet.

What can I do with it?

Set the size and age properties of an Event Log.

Example:

Set the following properties on the Application Log on the remote computer Test01:

Maximum Size = 5MB

OverflowAction = DoNotOverWrite

Limit-EventLog -ComputerName Test01 -LogName Application 
-MaximumSize 5MB -OverflowAction DoNotOverWrite

Before:

After:

How could I have done this in PowerShell 1.0?

You could use WMI to set properties on an event log. For example to set the MaxFileSize of the Application Log to 5MB use the below. (Thanks to Richard Siddaway for the tip that you need to use psbase to save the changes, just Put() doesn’t work.)

$EventLog = Get-WmiObject -Class Win32_NTEventLogFile 
-Filter "LogFileName = 'Application'"
$EventLog.MaxFileSize = 5242880
$EventLog.psbase.Put()

1000 things 1% better!

PowerShell 2.0: One Cmdlet at a Time #65 New-EventLog

Continuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the New-EventLog cmdlet.

What can I do with it?

Create a custom Event Log.

Example:

Create a custom Event Log named App1 with an event source of AppEvent. Use the Get-EventLog cmdlet to confirm it has been created. Tip: New-EventLog requires a PowerShell session with elevated privileges.

New-EventLog -LogName App1 -Source AppEvent
Get-EventLog -List

You can see that the App1 Event Log has been created.

You can create entries in this log using the Write-EventLog cmdlet, e.g.

Write-EventLog -LogName App1 -Source AppEvent -ID 1020
-Message "Error 1020 has occured"

Here’s confirmation in Event Viewer that the App1 Event Log exists and we have created the above entry in it.

How could I have done this in PowerShell 1.0?

You could have used the .NET System.Diagnostics.EventLog class and the CreateEventSource method to create a custom event log.

$LogDetails = 
New-Object System.Diagnostics.EventSourceCreationData "AppEvent", "App1"
[System.Diagnostics.EventLog]::CreateEventSource($LogDetails)

1000 things 1% better!