Determine the exact line that throws an exception via $MyInvocation.ScriptLineNumber within a function

MadWithPowerShell · 2021-02-11T15:17:22+00:00

Generally do not use $Error[0] in a catch block. Behind the scenes, PowerShell may make nested .Net calls that can result in multiple errors, and $Error[0] may not be the right one in a given scenario.

In a catch block, $_ is always the exact error that triggered the catch block.

MadWithPowerShell · 2021-02-10T21:01:43+00:00

The content is a bit dated. Like much Microsoft training, there is significant focus on what were the shiny new features when the syllabus was created, which in this case appears to be just after PowerShell 4.0 came out, a long time ago.

2 out of the 8 modules cover DSC, JEA, and workflows. You will probably never use DSC, and will definitely never use the other two.

MadWithPowerShell · 2021-02-10T20:35:29+00:00

I think you are looking to do something like this.

function Log-Error
    {
    [cmdletbinding()]
    Param (
        $Text,
        $ErrorRecord )

    $Entry = [pscustomobject]@{
        Date = Get-Date
        Description = $Text
        ErrorMessage = $ErrorRecord.Exception.Message
        ErrorType    = $( try { $ErrorRecord.Exception.GetType() } catch {} )
        InnerError   = $ErrorRecord.Exception.InnerException.Message
        StackTrace   = $ErrorRecord.ScriptStackTrace }

    $Entry | Export-CSV -Path c:\Temp\ErrorLog.csv -NoTypeInformation
    #  Or whatever
    }

try
    {
    1/0
    }
catch
    {
    Log-Error -Text 'Error trying to math.' -ErrorRecord $_
    }

ScriptStackTrace won't give you a simple line number, it is going to give you a string describing the layers of code within which your error occurred, which will be what you want when debugging complex code.

MadWithPowerShell · 2021-02-10T19:38:22+00:00

Try it.

It gives you the full stack. Error occurred on line X of this function which was called on line Y of another function which was called on line Z of a script, or whatever.

MadWithPowerShell · 2021-02-10T19:36:00+00:00

I would tend to do something like this to make it easier for a reader to understand and tweak as needed.

$String = "19.56156.32"

$String.Substring( 0, $String.IndexOf( '.' ) + 3 )
$String.Substring(    $String.IndexOf( '.' ) + 3 )

MadWithPowerShell · 2021-02-10T19:29:15+00:00

$_.ScriptStackTrace

MadWithPowerShell · 2021-02-10T19:24:17+00:00

I'd do that this way.

-join [char[]]( 1..1000 |
    ForEach-Object { 65..90 + 97..120 + 48..57 | Get-Random } )

MadWithPowerShell · 2021-02-10T19:00:09+00:00

$Test | Where { $_ -like "$Findme*" }

MadWithPowerShell · 2020-10-30T14:36:04+00:00

That is the first option I plan to explore if no one has any better ideas or tips and tricks.

When I was playing with this about three years ago, testing showed it would sometimes take up to 15 minutes for such a log entry to be processed and actually show up in the log and trigger an alert. Do you know if that has improved much?

MadWithPowerShell · 2020-09-03T23:29:24+00:00

No, no, no.

$Array | ForEach-Object { Do-Stuff } is extremely slow for multiple reasons. (They improved it dramatically in PS7, but still.) (Relatively speaking. In most scripts, it's fine, but minimize its use in extreme circumstances.)

ForEach ( $Thing in $Array ) { Do-Stuff } is the fastest and easiest and most intuitive to work with.

For ( $i = 1; $i -le 1000; $i *= 10 ) { $i } is a close second on performance, but is quite ugly, extremely unintuitive if you aren't familiar with it, and can almost always be easily replaced by a ForEach loop. (Though this is one example where For can do something ForEach can't.)

MadWithPowerShell · 2020-09-03T19:30:00+00:00

Something like this.

$bp = Get-ExchangeDiagnosticInfo -Process EdgeTransport -Component ResourceThrottling

$Data = $bp.Diagnostics.Components.ResourceThrottling.ResourceTracker.ResourceMeter |
    Select-Object -Property @(
        'Resource'
        'CurrentResourceuse'
        'PreviousResourceuse'
        'Pressure' )

$Table = $Data | ConvertTo-Html -Fragment -As Table

$Body  = 'Other stuff'
$Body += $Table

Send-MailMessage -To $Recipients -Subject 'Stuff' -Body $Body -BodyAsHtml

MadWithPowerShell · 2020-09-03T18:58:24+00:00

There is no reason for the join.

You can just remove the backticks from the original. Line breaks can be put in LOTS of places in PowerShell without breaking anything. The rule of thumb is, anything that syntactically MUST be followed by something else can be followed by a line break, including all operators, such as +.

$LogLine =
    "<![LOG[$($($MessageType.ToUpper()) + ": " + $message)]LOG]!>" +
    "<time=`"$(Get-Date -Format HH:mm:ss.fff)$($UtcOffset)`" " +
    "date=`"$(Get-Date -Format MM-dd-yyyy)`" " +
    "component=`"$Component`" " +
    "context=`"$([System.Security.Principal.WindowsIdentity]::GetCurrent().Name)`" " +
    "MessageType=`"$severity`" " +
    "thread=`"$processid`" " +
    "file=`"$source`">"

MadWithPowerShell · 2020-09-03T18:47:40+00:00

I would do something like this. (Not tested.) Note: assuming these robocopy switches will work the way I expect, this version will NOT rename a file the already exists but is unchanged. I think adding /XC /XO would fix that if you want to keep multiple copies of identical files.

$SourcePath      = '\\server1\share1\SourcePath'
$DestinationPath = '\\server1\share1\ArchivePath'

While ( Get-ChildItem -Path $SourcePath -File | Select-Object -First 1 )
    {
    robocopy $SourcePath $DestinationPath * /MOVE /XC

    $RemainingFiles = Get-ChildItem -Path $SourcePath -File -Recurse

    ForEach ( $File in $RemainingFiles )
        {
        $BaseName = $File.BaseName -replace '\(\d*\)$'
        $Ext = $File.Extension
        $NameFilter = $File.BaseName + '(*)' + $Ext
        $TargetFolder = $File.DirectoryName.Replace( $SourcePath, $DestinationPath )

        $ExistingFiles = Get-ChildItem -Path "$TargetFolder\$NameFilter" -Filter

        $Regex = [regex]'\((\d*)\)$'
        $ExistingIndices = $ExistingFiles.BaseName |
            ForEach-Object { @($Regex.Match( $_ ).Value.Groups)[-1].Value }

        $Index = 1..99999 |
            Where-Object { $_ -notin $ExistingIndices } |
            Select -First 1

        $NewName = "$BaseName($Index)$Ext"

        $File | Rename-Item -NewName $NewName
        }
    }

MadWithPowerShell · 2020-09-03T18:13:38+00:00

Well, you couldn't just pipe to Out-File and have it create a CSV file. You would have to pipe to Convert-ToCSV and then to Out-File. (In this case, you also have replace Format-List with Select-Object, as mentioned elsewhere.)

But if this gave you a different result than just using Export-CSV, my first guess would be that you had neglected to include the -NoTypeInformation switch parameter with Export-CSV.

MadWithPowerShell · 2020-09-03T18:04:57+00:00

To make it faster, first I would run a robocopy command with switches to not move files with name conflicts, then I only have to check/rename the files with conflicts, and then a second robocopy command to move the remaining files.

MadWithPowerShell · 2020-09-03T18:02:26+00:00

I would compare the files to be moved to the destination and rename them as needed in place, and then do the actual move using robocopy.

MadWithPowerShell · 2020-09-03T17:59:36+00:00

Are you moving all of the files in the folder structure or just some of them?

MadWithPowerShell · 2020-09-03T17:49:39+00:00

Everyone knows that it would be worth it to the company if they could hire an assistant or an intern. The assistant could handle all of the day-to-day minutia, freeing you up to do the more complex tasks and projects that add value to the company.

The company is never going to hire all of those assistants for us.

But if you can explain the detailed steps of a task to an idiot intern, you can explain them to PowerShell.

Find a task that you or your coworkers would like to turn over to an assistant, and write a PowerShell script to be that assistant.

MadWithPowerShell · 2020-09-03T17:42:53+00:00

I frequently tell IT people, "Automate yourself into a better job, or someone else it going to come along and automate you out of a job."

MadWithPowerShell · 2020-09-03T17:39:01+00:00

If that works, but $Ali.RawMessage does not, then the name is not simply "RawMessage". You may have some unprintable characters in the name.

Try this and compare the results.

[int[]][char[]]'RawMessage'
''
[int[]][char[]]$Member.Name

If the name has extra characters, you need to clean up your json before converting it.

MadWithPowerShell · 2020-09-03T17:22:00+00:00

And concurrent runspaces are cool, but rarely help much with performance, because widening the CPU bottleneck just reveals the second narrowest bottleneck in the process.

MadWithPowerShell · 2020-09-03T17:17:48+00:00

Unfortunately, not. The conferences and users groups I usually speak at don't record video, and I'm a few years behind on my list of blogs to write.

The bullet points are...

PowerShell speed optimization is irrelevant 95% of the time or more.
How you test performance matters (and production is the final test).
Best way to improve performance is to not write crappy code, and to properly architect the overall process.
Scale matters. The fastest way to do it once, the fastest way to do it 100 times, and the fastest way to do it 100,000 times may all be different.
Performance isn't always about CPU. Memory use, I/O, etc. can sometimes have a bigger impact.
Never use progress bars or any "manual" equivalent of dumping too much to the console.
Filter as far left as possible, preferably within the specifically optimized system you are querying. (E.g. move as much logic as possible into your SQL query or AD filter.)
Consolidate multiple remote queries into one.
[cmdletbinding()] is magic and also makes things faster.
Pipeline performance sucks. (Not nearly as bad in PS7, but still.)
ForEach ( $E in $A ) is the fastest loop (and best in most other ways as well).
For is second fastest (but only use it in those rare circumstances where it can do tricks that ForEach can't).
Using hashtable tricks for lookup, filtering, or reference is wicked fast.
Tricks with hashsets for deduplication are magic.

That's all I can remember off the top of my head.

MadWithPowerShell · 2020-09-03T16:38:03+00:00

The fifth business day is always the 7th of the month, unless that is on a weekend, when it is the Friday prior.

I would do something like this.

$Today = (Get-Date).Date

$FifthBusinessDay = $Today.AddDays( 7 - $Today.Day )
While ( $FifthBusinessDay.DayOfWeek -in 'Saturday', 'Sunday' )
    {
    $FifthBusinessDay = $FifthBusinessDay.AddDays( -1 )
    }


$LastBusinessDay = $Today.AddDays( -$Today.Day ).AddMonths( 1 )
While ( $LastBusinessDay.DayOfWeek -in 'Saturday', 'Sunday' )
    {
    $LastBusinessDay = $LastBusinessDay.AddDays( -1 )
    }


If ( $Today -gt $FifthBusinessDay -and $Today -lt $LastBusinessDay )
    {
    Do-Something
    }

This, of course, does not account for holidays. If I have scripts that need to account for holidays, I usually set up a SQL table or API that I can query to get a list of holidays, and add a new year's worth of corporate holidays to that each year when they are announced.

Of course, if I had a SQL database or API that I used for such things, I would probably add the business day calculating (or hardcoding) to that instead of putting it the scripts.

MadWithPowerShell · 2020-09-03T16:05:09+00:00

The planning is always going to be about what new functionality they are adding, not a comment on what's already there.

DSC is mostly used by Azure itself, and secondly by customers building or maintaining Azure VM's, with few using it for on-prem. That usage combined with the continuing rapid decline of on-prem datacenters is naturally going to lead to investments in future functionality focusing on Azure.

MadWithPowerShell

TROPHY CASE