PAL v2.0 Alpha 4 Released

Feb 2, 2010 at 7:38 AM

FYI. I just released PAL v2.0 Alpha 4. Please try it out and let me know. Keep in mind that I have added the major Microsoft product thresholds, but only the operating system counter thresholds are working right now. This means that product counters will show up in the charts and stats, but not the thresholds. For example, SQL Server counters will be charted and have stats, but will not have threshold alerts except for operating system counters. We are working hard to get the thresholds active in these threshold files. In the meantime, if you need to have all of the product specific threshold alerts, then continue using PAL v1.3.6 for now. Thank you.

Feb 5, 2010 at 6:42 PM
Edited Feb 7, 2010 at 2:14 PM

Hi Clint,


Very nice. I'm just looking at the localization and getting a bit lost in the $BeginTime $Global:BeginTime variables however as relog uses "MM/dd/yyyy hh:mm:ss" I think we might be better off using that throughout the script and then just converting to localized for display purposes. This is compounded by the fact that the wizard passed a localized date to the command line so in the UK we get "29/01/2010 20:14:22"


To that end have converted the lines below to support this and removed "Function ConvertToTwentyFourHourTime" as I don't think we need it (please feel free to correct me). This should mean that the wizard works with local date formats and if you use the command line you can actually use local time format as it gets converted at runtime.


If ($BeginTime -ne $null)


        $global:BeginTime = ([datetime]::parseexact($BeginTime,$global:sDateTimePattern,$null)).tostring("MM/dd/yyyy HH:mm:ss")



    If ($EndTime -ne $null)


        $global:EndTime = ([datetime]::parseexact($EndTime,$global:sDateTimePattern,$null)).tostring("MM/dd/yyyy HH:mm:ss")



Also updated (to make chart x axis localised)


[Void] $SeriesOfCounterValues.Points.AddXY($aDateTimes[$b], $aValues[$b])


[Void] $SeriesOfCounterValues.Points.AddXY(([datetime]$aDateTimes[$b]).tostring($global:sDateTimePattern), $aValues[$b])


I had to update "ConvertAnalysisIntervalIntoHumanReadableTime" to use the $Global  'begintime' and 'endtime' and added "$sInterval=$null" otherwise it fell foul of the "Set-StrictMode"


$Global:BeginTime = Get-Date

$Global:EndTime = $Global:BeginTime.AddSeconds($TimeInSeconds)

$DateDifference = New-TimeSpan -Start ([DateTime]$Global:BeginTime) -End ([DateTime]$Global:EndTime)




If ($DateDifference.Seconds -gt 0)


Finally I updated "$global:BeginTime = $BeginTime" just under "$global:sDateTimePattern = (get-culture).datetimeformat.ShortDatePattern + " " + (get-culture).datetimeformat.LongTimePattern" to "$global:BeginTime = $null" just so we are sure it's set to something but we don't confuse the localization.


p.s. hope you don't mind me tinkering in the code like this.



Feb 17, 2010 at 12:35 PM

PAL V2 and Time zones

I experienced some problems running PAL V2 on an XP machine using Frecnh settings.

Among these settings is a time zone whose text contains " ... Paris, Madrid ..." : the problem is with the comma after Paris which breaks the split located at line 1402 : $aRawCounterList = $oCSVFile[0].Split(",")

Having no quick solution, I changed my time zone to another one without comma in the text ......

I guess that the culprit is relog.exe which should quote the comma inside time zone text. Is it correct ?

I suggest you issue a warnig to PAL users located in "commas" time zones.


Feb 19, 2010 at 10:19 AM

Hi gcany

Can you post the command line the wizard has created so I can take a look at the format and see if the fixes I posted above will take care of it.


Mar 5, 2010 at 9:24 PM


Sorry for taking so long to respond. Work keeps my busy.

I'm fine with using the same date time format internal to PAL processing and localizing the date displayed. My concern is Relog.exe. I don't know if the format is different on non-English systems. I'll look into this and I will consider your code. Thank you for the help!