-
PowerShell 2.0: One Cmdlet at a Time #75 Remove-Module
Posted on March 12th, 2010 No commentsContinuing the series looking at new cmdlets available in PowerShell 2.0. This time we look at the Remove-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. Remove-Module enables you to remove a module previously imported with Import-Module.
Example:
Check currently available modules with Get-Module and remove the PSDiagnosticsModule.
Get-Module Remove-Module PSDiagnostics
How could I have done this in PowerShell 1.0?
If you had imported a PSSnapin with Add-PSSnapin you could remove it with Remove-PSSnapin.
-
PowerShell 2.0: One Cmdlet at a Time #74 Test-ModuleManifest
Posted on March 11th, 2010 No commentsContinuing 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
-
PowerShell 2.0: One Cmdlet at a Time #73 New-ModuleManifest
Posted on March 10th, 2010 No commentsContinuing 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-ModuleManifestYou 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
-
PowerShell 2.0: One Cmdlet at a Time #72 Export-ModuleMember
Posted on March 5th, 2010 No commentsContinuing 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
-
PowerShell 2.0: One Cmdlet at a Time #71 New-Module
Posted on March 4th, 2010 No commentsContinuing 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.
-
PowerShell 2.0: One Cmdlet at a Time #70 Import-Module
Posted on March 3rd, 2010 No commentsContinuing 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
-
PowerShell 2.0: One Cmdlet at a Time #69 Get-WinEvent
Posted on March 2nd, 2010 No commentsContinuing 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}
-
PowerShell 2.0: One Cmdlet at a Time #68 Show-EventLog
Posted on February 26th, 2010 No commentsContinuing 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
-
PowerShell 2.0: One Cmdlet at a Time #67 Remove-EventLog
Posted on February 26th, 2010 No commentsContinuing 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
Posted on February 23rd, 2010 No commentsContinuing 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()























