Happy SysAdm

Monday, May 13, 2013

Powershell Scripting Games event 2

Voting has started for the second assignment of the 2013 Powershell Scripting Games. This second task was very tough for me because I was on holiday at the seaside and had no fixed Internet connection and no Windows 2000 nor Windows 2003 test machine to test my script with. Anyhow I managed to answer the assignment by using MSDN and checking there which WMI classes I could query depending on the operatin system version.

But let's go back a bit. Here's the full task assignment:

"Dr. Scripto finally has the budget to buy a few new virtualization host servers, but he needs to make some room in the data center to accommodate them. He thinks it makes sense to get rid of his lowest-powered old servers first… but he needs to figure out which ones those are.

This is just the first wave, too – there’s more budget on the horizon so it’s possible he’ll need to run this little report a few times. Better make a reusable tool.

All of the virtualization hosts run Windows Server, but some of them don’t have Windows PowerShell installed, and they’re all running different OS versions.The oldest OS version is Windows 2000 Server (he knows, and he’s embarrassed but he’s just been so darn busy). The good news is that they all belong to the same domain, and that you can rely on having a Domain Admin account to work with.

The good Doctor has asked you to write a PowerShell tool that can show him each server’s name, installed version of Windows, amount of installed physical memory, and number of installed processors. For processors, he’ll be happy getting a count of cores, or sockets, or even both – whatever you can reliably provide across all these different versions of Windows. He has a few text files with computer names – he’d like to pipe the computer names, as strings, to you tool, and have your tool query those computers."

When I saw the scenario I was I little scared by the fact of having to handle all the possible operating systems since Windows 2000. I highlighted the critical points that need to be addressed by the script. I for sure came up with a function in roder to answer to the need of a reusable tool.

Here's the script I wrote:

#Requires -Version 3.0
Function Get-Inventory {
<#
.SYNOPSIS
Collect important information about a system's hardware in order to decide which ones are too low-powered.
.DESCRIPTION
This function will collect the following information about the target computer:
- computer name,
- operating system version,
- the amount of physical memory,
- number of processors,
- number of cores,
- number of sockets
This function has the three classic Begin, Process and End block.
- In the Begin block I prepare the ScriptBlock which contains the WMI queries and which is called in the process block.
- In the process block I perform Job setup and Jobs throttling.
- In the End block I return the results in the form of a object or of a GridView.
.PARAMETER ComputerName
Gets the services running on the specified computer. The default is the local computer.
Type the NetBIOS name, an IP address, or a fully qualified domain name of a remote computer.
To specify the local computer, type the computer name, a dot (.), or "localhost".
This parameter does not rely on Windows PowerShell remoting.
You can use the ComputerName parameter even if your computer is not configured to run remote commands.
.PARAMETER Credential
Specifies a user account that has permission to perform this action.
This parameter allows you to supply either a PSCredential object or you can specify the domain\username and it will open up
the credential window to type in a password.
.PARAMETER Grid
Use this switch to visualize inventory data in the new GridView format for better filtering.
.EXAMPLE
To report on localhost:
Get-Inventory
.EXAMPLE
To report on a list of servers from a text file:
Get-Inventory -ComputerName (Get-Content c:\servers.txt)
.EXAMPLE
To report on all available servers in a domain, and see the results in a grid, use the following syntax:
Get-Inventory -ComputerName ( ([adsisearcher]"objectCategory=computer").findall() | ForEach-Object { $PSItem.properties.cn } ) -Grid
.EXAMPLE
To report against a specif server:
Get-Inventory -ComputerName "alphaserver"
.NOTES
Entry for 2013SG Advanced Event 2. To use, dot source script and run 'Get-Inventory'.
Use 'get-help Get-Inventory -full' to see how to run complete help.
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$false, ValueFromPipeline=$True, ValueFromPipelineByPropertyName=$true)]
# Binding by default to localhost.
[Alias('CN','__Server')]
[String[]]$ComputerName = $env:COMPUTERNAME,
[Parameter(Mandatory=$false)]
[System.Management.Automation.PSCredential]
[System.Management.Automation.Credential()]$Credential = [System.Management.Automation.PSCredential]::Empty,
[Parameter(Mandatory=$false)]
[switch]$Grid = $false
) # End parameter definition.
Begin {
Write-Verbose "Started at $(get-date)."
# Setting up an array to keep al the objects returned from this function.
$AllComputerData = @()
# Setting up an array to store all the remote jobs.
$Jobs = @()
# Number of max computers to query at the same time. This parameter throttle WMI queries in order not to overload the Inventory server.
$MaxConcurrentJobs = 10
# Checking if current is has administrator token for WMI queries.
Write-Verbose "Checking for admin rights."
$CurrentUser = [Security.Principal.WindowsIdentity]::GetCurrent()
$TestAdmin = (New-Object Security.Principal.WindowsPrincipal $CurrentUser).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
if (!$TestAdmin)
{
Throw "This script must be run with elevated privileges. Try tu use -Credential parameter and suplly administrative credentials. Exiting..."
}
else
{
Write-Verbose "Admin rights OK. Continuing."
}
# Scriptblock. Here is where everything happens. This scriptblock is called inside the Process block for each server to query.
$Sb = {
# The parameter $Computer is passed by Start-Job as an argument for consistency. I could have used args[0] too.
param($Computer)
# Checking if ping works..
if(!(Test-Connection $Computer -Quiet -ea 0 -Count 2))
{
# Ping failed!!!
# Creating a dummy object for servers not pinging. I added the Ordered key to keep columns in the order I want.
$Result = New-Object –TypeName PSObject –Property ([ordered]@{
'Computer Name'= $computer
'State' = "Not pinging"
'Operating System'= "N/A"
'Physical Memory'= "N/A"
'Number Of Processors'= "N/A"
'Number of Cores'= "N/A"
'Number of Sockets'= "N/A"
})
} # End if.
else
{
# Server pings. Checking WMI in a Try Catch block.
try
{
#Adding splatting to keep the line for WMI queries not too long
$Parms = @{
"Computername" = $Computer;
"ErrorAction" = "Stop";
"ErrorVariable" = "MyErr";
"Impersonation" = "impersonate"
}
# Retrieving the three needed WMI instances: Win32_OperatingSystem, Win32_ComputerSystem and Win32_Processor.
$OperatingSystem = Get-WmiObject Win32_OperatingSystem -property Caption @Parms
$ComputerSystem = Get-WmiObject Win32_ComputerSystem -property Name,TotalPhysicalMemory,NumberOfProcessors @Parms
$Processor = Get-WmiObject Win32_Processor -Property SocketDesignation,Numberofcores @Parms
# Retrieving information about cores and sockets
$NumberOfCores = 0
$NumberOfSockets = 0
[string]$String = $null
foreach ($Proc in $Processor)
{
# Checking if the NumberOfcores property is present in Win32_Processor. If it is not the case, then it's a Windows 2003 or older.
if ($Proc.numberofcores -eq $null)
{
# Checking if SocketDesignation property is available for each instance of Win32_Processor.
# If it is present I increment the $NumberOfSockets counter.
If (-not $String.contains($Proc.SocketDesignation))
{
$String = $String + $Proc.SocketDesignation
$NumberOfSockets++
}
# In Windows 2003 and older there is one instance of Win32_Processor for each core.
# So I am incrementing this counter for each instance.
$NumberOfCores++
}
else
{
# Since Windows Server 2008 and Windows Vista:
# - for the Number of Cores, there is a NumberOfCores property. Easy.
# - for the Nymber of Sockets, each instance of Win32_Processor is a socket. Incrementing this counter for each instance.
$NumberOfCores = $NumberOfCores + $Proc.numberofcores
$NumberOfSockets++
}
} # End of foreach loop used to retrieve information on sockets and cores.
# Retrieving Physical Memory
$PhysicalMemory = $ComputerSystem.TotalPhysicalMemory
# Converting installed RAM to the most appropriate unit. it's a bit long but it makes results easy to read for humans.
Switch ($PhysicalMemory)
{
{($PhysicalMemory -gt 1024) -and ($PhysicalMemory -le 1048576)}
{
# Better to use KB.
$PhysicalMemory = $PhysicalMemory/1Kb
$PhysicalMemory = [math]::Round($PhysicalMemory, 2)
$PhysicalMemory = [string]$PhysicalMemory + ' KB'
Break
}
{($PhysicalMemory -gt 1048576) -and ($PhysicalMemory -le 1073741824)}
{
# Better to use MB.
$PhysicalMemory = $PhysicalMemory/1Mb
$PhysicalMemory = [math]::Round($PhysicalMemory, 2)
$PhysicalMemory = [string]$PhysicalMemory + ' MB'
Break
}
{($PhysicalMemory -gt 1073741824)}
{
# Alot of memory here. Better to use GB.
$PhysicalMemory = $PhysicalMemory/1Gb
$PhysicalMemory = [math]::Round($PhysicalMemory, 2)
$PhysicalMemory = [string]$PhysicalMemory + ' GB'
}
default
{
# Bytes maybe.
$PhysicalMemory = [math]::Round($PhysicalMemory, 2)
$PhysicalMemory = [string]$PhysicalMemory + ' B'
}
} # End Switch.
# Preparing a PSObject and filling it with hardware and operating system information. Keeping columns in order with Ordered key.
$Result = New-Object –TypeName PSObject –Property ([ordered]@{
'Computer Name'= $ComputerSystem.Name
'State' = "Ping and WMI OK"
'Operating System'= $OperatingSystem.Caption
'Physical Memory'= $PhysicalMemory
'Number Of Processors'= $ComputerSystem.NumberOfProcessors
'Number of Cores'=$NumberOfCores
'Number of Sockets'=$NumberOfSockets
})
} # End Try, starting Catch.
Catch
{
# Cought WMI error.
"WMI Query for $computer failed."
"The error was: $MyErr"
# Preparing a dummy object for servers that did not answer WMI query.
$Result = New-Object –TypeName PSObject –Property ([ordered]@{
'Computer Name'= $computer
'State' = "Ping OK but WMI Query failed"
'Operating System'= "N/A"
'Physical Memory'= "N/A"
'Number Of Processors'= "N/A"
'Number of Cores'= "N/A"
'Number of Sockets'= "N/A"
})
} # End Catch block.
} # End if else
# Returning the result for this server to the calling function.
Return $Result
} # End of Scriptblock
} # End Begin section
Process {
foreach ($Computer in $ComputerName) {
# Preparing a progress bar to be used if the number of servers to query is greater than 1.
# The parameters for the progress bar are stored in a variable named $ProgressSplatting.
if ($ComputerName.Count -gt 1) {
$ProgressSplatting = @{
Activity = 'Inventorying:'
Status = $Computer
Id = 1
PercentComplete = ([array]::IndexOf($ComputerName, $Computer))/$ComputerName.Count*100
}
Write-Progress @ProgressSplatting
}
#Replacing dot and localhost with proper computername.
switch ($computer)
{
"." {$computer="$env:COMPUTERNAME"}
"localhost" {$computer="$env:COMPUTERNAME"}
}
Write-Verbose "Starting job for $Computer"
# Adding a job for each server in the pipe.
$Jobs += Start-Job -ArgumentList $Computer -ScriptBlock $sb
$Running = @($Jobs | Where-Object {$PSItem.State -eq 'Running'})
# Throttling jobs
while ($Running.Count -ge $MaxConcurrentJobs)
{
write-verbose "Waiting for all jobs to complete"
$Finished = Wait-Job -Job $Jobs -Any
$Running = @($Jobs | Where-Object {$PSItem.State -eq 'Running'})
} # End while loop.
} # End of foreach loop against each server.
# Waiting for every job inside $Jobs array to finish.
Wait-Job -Job $Jobs > $Null
Write-Verbose "All jobs finished!"
} # End Process block.
End {
# Receiving content of jobs and storing them in a $AllComputerData array.
$Jobs | ForEach-Object { $AllComputerData += $PSItem | Receive-Job }
Write-Verbose "Finished at $(get-date)."
if($Grid)
{
# If you selected the -Grid parameters I am going to show the results in a GridView.
Write-Verbose "Displaying output in a GridView."
$AllComputerData | Out-GridView
}
else
{
# Returning an object for post-processing.
Write-Verbose "Returning the array that contains all the inventory results."
Return $AllComputerData
} # End If
} # End of End block
} # End of Function Get-Inventory
Get-Inventory -ComputerName . -Verbose

For the moment my script was very well received, since I am in the Top 10 as you can see here:

This is a huge result for me since I din't spend more than three hours coding and that I had no test machine apart from my laptop.

I tried to be as prolific as I could, so I added jobs, which is a must when you are querying a lot of remote hosts. I also added the possibility to show the result in a GridView, which is a new feature of Powershell.

To vote for me on this entry, visit the link below and click on the rightmost star (5 stars)!

Thanks for your support!

Powershell Scripting Games Event 1, lesson learned

The 2013 Powershell Scripting Games have started for real. I am competing this is for the firs time in the Advanced category. For the moment two tasks have been published. In the first one we had to develop a function aimed at moving old logfiles to a location off the system drive. Easy right? Well, not really. The judges (as well as the other competitors) are very nitty-picky and I have soon discovered that any small mistake can bring very low scores.

Even tough I paid careful attention to what I was doing, I overlooked a few things which I want to share here.

Here's the function I wrote for the assignment:

#Requires -Version 3.0
set strict-mode latest
function Archive-Logs {
<#
.SYNOPSIS
Archives application logs older than a certain amount of days to a specific location.
.DESCRIPTION
Moves all the application logs older than a certain amount of days to a specific location.
The subfolder structure is maintained.
.PARAMETER SourcePath
Specifies the current path of the folder containing the logs to be moved.
.PARAMETER DestinationPath
Specifies the destination path where to recreate the subfolders structure and move the logs.
.PARAMETER Days
Specifies the minimum age in days of the logs that have to be archived.
The default is 90 days.
.PARAMETER Log
Switch parameter to enable error logging.
The default is False.
.PARAMETER FailedLogFile
Specifies the path of the file where the errors are logged if the Log switch is set to True.
The default is $env:temp\failed-log-move.log
.PARAMETER ViewErrorLog
Opens the error log for viewing using the default associated program (i.e. Notepad).
The default is False.
.EXAMPLE
Archives logs older than 100 days from C:\Application\Log to \\nasserver\Archives
Archive-Logs C:\Application\Log \\nasserver\Archives 100
.EXAMPLE
Archives logs older than 100 days from C:\Application\Log to \\nasserver\Archives. It also logs errors to $env:temp\failed-log-move.log and opens this log for reading.
Archive-Logs C:\Application\Log \\nasserver\Archives 100 -Log -ViewErrorLog
.EXAMPLE
Archives logs older than 2 years from C:\Application\Log to \\nasserver\Archives and shows verbose output
Archive-Logs C:\Application\Log \\nasserver\Archives 730 -Verbose
.EXAMPLE
Simulates archival of logs older than 3 months from C:\Application\Log to d:\backup
Archive-Logs C:\Application\Log d:\backup 90 -Whatif
.NOTES
Entry for 2013SG Advanced Event 1. To use, dot source script and run 'Archive-Logs'.
Use 'get-help Archive-Logs -full' to see how to run complete help.
This function leverages Powershell V3 cmdlets and parameters, such as OlderThan in Test-Path or $PSItem instead of $_.
I am also taking advantage of Get-ChildItem -File and -Directory.
#>
[CmdletBinding(SupportsShouldProcess=$True)]
param(
[Parameter(Mandatory, Position=0)]
[ValidateScript({Test-Path $_ -PathType Container})]
[String]$SourcePath,
[Parameter(Mandatory, Position=1)]
[ValidateScript({Test-Path $_ -PathType Container})]
[String]$DestinationPath,
[Parameter(Mandatory=$False, Position=2)]
[Int]$Days = 90,
[Parameter(Mandatory=$False, Position=3, ParameterSetName = 'Logging')]
[Switch]$Log = $False,
[Parameter(Mandatory=$False, Position=4, ParameterSetName = 'Logging')]
[ValidateScript(
{
Try {
Add-Content -LiteralPath $_ -Value $null -ErrorAction Stop
$true
}
Catch { $false }
})]
[String]$FailedLogFile=(Join-Path $env:Temp 'failed-log-move.log'),
[Parameter(Mandatory=$false, Position=5, ParameterSetName = 'Logging')]
[switch]$ViewErrorLog = $false
)
Write-Verbose ("Script started processing at {0:hh}:{0:mm}:{0:ss}" -f (Get-Date))
$ErrorTracker = 'without errors'
ForEach($SubFolder in (Get-ChildItem $SourcePath -Directory))
{
$DestSubFolder = Join-Path -Path $DestinationPath -ChildPath $SubFolder
if(!(Test-Path $DestSubFolder))
{
Try {
[void] (New-Item -path $DestinationPath -name $SubFolder -ItemType directory -Force -ErrorAction Stop)
}
Catch
{
Write-Warning "Failed creating $SubFolder in $DestinationPath"
$ErrorTracker = 'with errors'
if ($Log)
{
Add-Content -LiteralPath $FailedLogFile -Value "$(Get-Date) - Failed creating $SubFolder in $DestinationPath"
}
} # end Try/Catch
}
Try {
$OldLogs = Get-ChildItem -Path $SubFolder.FullName -Recurse -File -Include *.log -ErrorAction Stop |
Where-Object { Test-Path -Path $PSItem.FullName -OlderThan (Get-Date).AddDays(-$Days) }
}
Catch
{
Write-Warning "An error occurred retrieving logs from $($SubFolder.fullname)"
$ErrorTracker = 'with errors'
if ($Log)
{
Add-Content -LiteralPath $FailedLogFile -Value "$(Get-Date) - An error occurred retrieving logs from $($SubFolder.fullname)"
}
} # end Try/Catch
if($OldLogs)
{
$OldLogs | Foreach-Object {
Try {
$CurrentLog = $PSItem
Write-Verbose "Archiving $($CurrentLog.name) [$($CurrentLog.lastWriteTime)]"
$CurrentLog | Move-Item -Destination $DestSubFolder -Force -ErrorAction Stop
}
Catch {
Write-Warning "An error occurred moving $($CurrentLog.fullname)"
$ErrorTracker = 'with errors'
if ($Log)
{
Add-Content -LiteralPath $FailedLogFile -Value "$(Get-Date) - An error occurred moving $($CurrentLog.fullname)"
}
} # end Try/Catch
}
}
} # end ForEach-Object
Write-Verbose ("Script finished processing $ErrorTracker at {0:hh}:{0:mm}:{0:ss}" -f (Get-Date))
if($ViewErrorLog)
{
& $FailedLogFile
}
} # end Function Archive-Logs

Apparently everything is well. Unfortunately there are a few mistakes that make me score 2.8 out of 5 possible points.

Let's start with the biggest mistake, which is:

Get-ChildItem -Path $SubFolder.FullName -Recurse -File -Include *.log -ErrorAction Stop

The problem here is that I have misinterpreted the use of Get-ChildItem. When I tell this cmdlet to Recurse, I am going to return also files which are stored in any subdirectory. At the same time if I omitted this switch, no files where returned.

The solution to this, I give credit to Mike for this, was to include the desired file extension into the Path parameter:

Get-ChildItem -Path (Join-Path -Path $SourcePath -ChildPath '*\*.log') -ErrorAction Stop

The lesson I get from this is always to read the cmdlet full help, even if I am pretty sure of how it works.

Another big error of mine was not to comment enough. Many people stated that my script was hard to follow. The fact is that I deemed unnecessary to explain how my code worked to people who already have a proficient knowledge of Powershell. I was wrong.

The lesson I get from this is always to put comments before complicated lines of code as well as the end of each scriptblock. Here's two examples:

foreach ($Computer in $ComputerName) {
... any action ...
} # end of foreach $Computer

if($pingworks){
get-wmiobject...
} # end of If block

This makes my script much more readable.

The final thing that I learned from Event 1 and that I want to share with you is never to use superflous code. An example could be specifying that a parameters is not mandatory:

[Parameter(Mandatory=$False]

This is unneded in Powershell. So better to omit it.

That's all for the for Event 1. If you want to see it on the ScriptingGames website click on the image. Unfortunately is too late to vote for my entry on this assignment.

In the next post I will talk about the Second Event of the Games. Stay tuned!

Wednesday, April 24, 2013

The Scripting Games are about to start!

A few hours left to the 2013 Powershell Scripting Games! I am very excited because for the first time I will be taking part in such a competition. In the meanwhile, to stay focused on my objective of learning as much as possible, I am browsing the Net and reading some pretty interesting resources.

Heres' a list:

The two first posts by Jeffery Hicks about the evolution of Powershell toward CIM and WSMAN (post 1, post2).
An article of The Scripting Guy about WMI classes related to disks (see here).
Another post by Ed Wilson on using Get-ADComputer (see here)
A post by jeff Wouters about Compare-Object (see here)
A post by Richard Siddaway on updating the Help for V3 (see here)
... and last but not least a post by Bartek Bielawski on $Matches automatic variable

In the meantime I have just downloaded the Windows Management Framework 3 for one of my Windows 7 x64 SP1 (6.1.7601) computers and when I tried to run it quit saying 'The update is not applicable to your computer'.

The problem here is that I though I had .NET 4.0 installed on that computer and I was wrong. When I run the WMI query to verify that .NET 4 was installed I got the following result and I thought it was good:

Get-WmiObject Win32_Product | where { $_.name -match '.NET Framework 4'}

Name              : Microsoft .NET Framework 4 Client Profile
Vendor            : Microsoft Corporation
Version           : 4.0.30319
Caption           : Microsoft .NET Framework 4 Client Profile

Unfortunately having this is not enough. For reference, after I installed the real Full version of the .NET 4 framework, the previous query returned:

Get-WmiObject Win32_Product |where { $_.name -match '.NET Framework 4'}

Name              : Microsoft .NET Framework 4 Extended
Vendor            : Microsoft Corporation
Version           : 4.0.30319
Caption           : Microsoft .NET Framework 4 Extended

Name              : Microsoft .NET Framework 4 Client Profile
Vendor            : Microsoft Corporation
Version           : 4.0.30319
Caption           : Microsoft .NET Framework 4 Client Profile

Much better!

Ok, the Games are coming in about 8 hours. Go and register if you want to compare your knowledge to other Powershell aficionados. This is the link to the registration form. Tomorrow it will be too late!

Monday, April 22, 2013

New Powershell 3.0 params for Get-ChildItem and Test-Path

Regarding Powershell 3.0 new parameters, today I want to talk about something pretty new and interesting that some of you may yet not to be aware of and that could be useful for your administration tasks. The parameters I am referring to are:

File
Directory
Newerthan
Olderthan

The first two parameters are new to Get-Childitem cmdlet and are used to return either the files or the folder in a specific path. They replace the check on PSIsContainer to determine if an object is a folder or a file. Let's see an example of each:

PS C:\>  Get-Childitem c:\windows -File

    Directory: C:\windows

Mode   LastWriteTime            Length Name
----   -------------            ------ ----
-a---  26/07/2012     05:08      75264 bfsvc.exe
-a--s  19/04/2013     16:27      67584 bootstat.dat
-a---  16/03/2013     16:34       1720 DtcInstall.log
-a---  26/07/2012     06:49    2380440 explorer.exe
-a---  26/07/2012     05:08     883712 HelpPane.exe
-a---  26/07/2012     05:08      17408 hh.exe
-a---  25/07/2012     22:37      43131 mib.bin
-a---  19/04/2013     16:24       4626 PFRO.log
-a---  26/07/2012     05:08     159232 regedit.exe
-a---  25/07/2012     22:15      27120 ServerWeb.xml
-a---  16/03/2013     16:34      12813 setupact.log
-a---  26/07/2012     09:13          0 setuperr.log
-a---  26/07/2012     05:08     126464 splwow64.exe
-a---  26/07/2012     07:26        219 system.ini
-a---  26/07/2012     09:21       1585 vmgcoinstall.log
-a---  26/07/2012     07:26         92 win.ini
-a---  26/07/2012     05:21      10752 winhlp32.exe
-a---  26/07/2012     05:08      10752 write.exe

PS C:\> Get-Childitem c:\windows\logs\* -Directory

    Directory: C:\windows\logs

Mode   LastWriteTime     Length Name
----   -------------     ------ ----
d----  26/07/2012     10:04            BPA
d----  16/03/2013     16:36            CBS
d----  16/03/2013     16:48            DISM
d---s  26/07/2012     10:04            MeasuredBoot

The third and fourth parameters are new to the Test-Path cmdlet and are used to check whether a given path is older or newer than a specific DateTime object. They have been added to replace the check on the LastWriteTime property, which was far too laborious.

PS C:\> Test-Path -Path c:\windows\logs -NewerThan "April 01, 2013 10:00 PM"
False

As you can see the resulting output is either True or False, depending on the result of the comparison. So, if we change -Newerthan into -Olderthan for the same folder we get True:

PS C:\> Test-Path -Path c:\windows\logs -OlderThan "April 01, 2013 10:00 PM"
True

Now you might be wondering why I present the parameters for two different cmdlets in the same post. Well, this is because you can make use of both together to find all the files older than a given date (i.e. in order to archive them or to delete them, this is up to you).

Here's a sample one-liner that can be used to find all the files older than 5 years in two file paths:

PS C:\> 'd:\IISlogs','h:\application_logs' | Get-ChildItem -File -Recurse -Force | ? { Test-Path -Path $_.FullName -OlderThan (Get-Date).AddYears(-5) }

I hope you will find this post useful and that you are getting used to the new Powershell 3.0 syntax. Keep in mind that this is a generic one-liner that has to be customised upon your needs. If you have any question, feel free to leave a comment.

Friday, April 19, 2013

Problem staging VMWare patches due to SSL inspection

Two months ago I described a problem with downloading patches for a brand new vCenter 5.1 and VMWare Update Manager installation. Today I faced the same problem upgrading an existing vCenter 5.0 to 5.1 where the SslVerifyDownloadCertificate parameter had already been set to 0:

Download patch definitions

Web sites:

https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml;https://hostupdate.vmware.com/software/VUM/PRODUCTION/cscomain/cscodepot-index.xml;

hosting the patch definitions and patches cannot be accessed or have no patch data. Check the Internet connectivity.

Heres' a screenshot of this error message:

Solved (as described in the other post) by setting once again that registry key from 1 to 0.

Wednesday, April 3, 2013

Finding paths that exceed MAX_PATH with Powershell

A lot as been said and written about the infamous MAX_PATH limitation imposed by the Windows API. Still in 2013 this keeps being a major pain for Windows File Server administrators and as such has been over-discussed but never properly solved. My opinion is that, unless a major architectural rework is done at Redmond, it is up to system administrators to keep an eye on their filesystems and try to evite as much as possible to have paths going over that hardcoded maximum.

That's why I want to share the Powershell script I use to find those paths that exceed 260 characters in lenght, being 260 the value of MAX_PATH ever since.

function Get-Longpaths {
<#
.SYNOPSIS
Retrieves a list of the paths that are too long for being managed with get-childitem.
.DESCRIPTION
Retrieves a list of the paths that are too long for being managed with get-childitem.
An object is returned containing the list of the paths longer then 260 characters.
The aim of this function is to help sysadmins to handle paths which could cause the
“System.IO.PathTooLongException“ due to their excessive length comared to what is
supported by .NET and Windows API.
.PARAMETER Path
The parent path that you need to recursively check.
.PARAMETER Csvpath
The name of the csv log file you optionally want to export your list of long paths to.
.EXAMPLE
Get-Longpaths c:\
Retrieves long path on the system partition c: and show on the current host.
.EXAMPLE
Get-Longpaths f:\documents c:\mylogs\longpathnames.csv -verbose
Retrieves long path inside the folder f:\documents and saves the
output to a csv file named longpathnames.csv under c:\mylogs\.
It also shows additional information on the task being performed.
#>
[CmdletBinding()]
param(
[Parameter(Mandatory=$true)]
[string] $Path,
[Parameter(Mandatory=$false)]
[string] $csvlog
)
$options = [system.IO.SearchOption]::AllDirectories
$allfiles = [system.IO.Directory]::GetFiles($path, "*",$options)
$allfolders = [system.IO.Directory]::GetDirectories($path, "*",$options)
$toolongcontainer = @()
foreach($file in $allfiles)
{
if($file.Length -gt 259)
{
write-verbose "Adding $file to the list of too long paths"
$toolongcontainer += $file
}
}
foreach($folder in $allfolders)
{
if(($folder|out-string).Length -gt 259)
{
write-verbose "Adding $folder to the list of too long paths"
$toolongcontainer += $folder
}
}
if(!($toolongcontainer))
{
write-verbose "No too long paths found. Good."
$toolongcontainer = "No invalid path under $path"
}
if($csvlog)
{
write-verbose "Exporting output to $csvpath"
$toolongcontainer | Export-Csv -Path $csvpath -NoTypeInformation -USECULTURE -ErrorAction Stop
}
return $toolongcontainer
}
Get-Longpaths C:\longpath -verbose

As you can see I used the methods GetFiles and GetDirectories of the system.IO.Directory class. In particular GetFiles returns the names of files in a specified directory, while GetDirectories gets the names of the subdirectories. The cool thing with this methods is that, for some mystical reasons explained here and here, they return the full path as a string or arrays and that's all we need.

Then all the objects returned by these two methods are added as strings to a string array named $toolongcontainer for later analysis. The content of this object can be sent to a CSV file as a record by passing the csv file path as a parameter.

Once you have this information, you can take appropriate actions such as shortening the path, deleting files and folders that exceed MAX_PATH or moving them to a shorter path. This is up to you.

If you need any clarification about this script, feel free to leave a comment and I'll be happy to answer. But remember that the easier way to get help for a function is to dot source the script then use the built-in help function this way: man Get-Longpaths -full where 'man' is an interesting alias for get-help.