I have been working on a few Exchange installs recently which have not gone completely according to plan. Normally when Exchange setup fails my first stop are the logs which are produced by the Exchange Setup process. These are typically located in “c:\ExchangeSetupLogs”.
There are normally quite a lot of files within this folder which detail the steps, processes, return results and errors of the Exchange setup processes. These files typically contain large amounts of data (as you would expect) so going through them manually can be a bit of a pain, unless of course the error is obvious!
However, in Exchange 2007 and 2010 – Microsoft provide a script in the $exscripts folder which helps “parse” the output of the logs files to make it easier for you to interpret the output. This script is called Get-SetupLog.ps1 and is covered in detail in this post over on the MSExchangeTeam’s blog.
Interestingly enough this script does not appear to be present in the $exscripts folder in Exchange 2013 – however, it appears that it still works with Exchange 2013 setup logs.
Anyway – back to my failed Exchange setups. I found that one the server where Exchange setup had failed I was getting the following error when trying to run the script:
Exception calling "Add" with "1" argument(s): "String was not recognized as a valid DateTime.Couldn't store <12/30/2012 20:13:52.0010> in DateTime Column. Expected type is DateTime." At C:\Program Files\Microsoft\Exchange Server\V14\scripts\get-setuplog.ps1:107 char:52 + $currrow = $dataset.Tables['setuptable'].Rows.Add <<<< ($holder) + CategoryInfo : NotSpecified: (:) , MethodInvocationException + FullyQualifiedErrorId : DotNetMethodException
The command line that I had used was:
.\get-setuplog.ps1 <path to Exchange Setup Logs>
After some investigation in my lab I found that on some of my Exchange servers the script would run correctly, however on others it would give me the errors shown above. The interesting thing that I noticed about the above PowerShell error was that it was being thrown when the script was attempting to parse DateTime values into a DataSet.
This started me thinking about what could be causing this – and what the difference could be between the servers where the script executed correctly and where it didn’t. I came up with Regional and Locale settings.
Sure enough, I found that on the server where the script ran correctly; the Regional Settings were set to en-US (United States) – and the server where the script did not run were set to en-GB ~ I tested this by changing the Regional settings on one of the servers in the lab and the script then ran fine.
Now, I did not wish to set the Regional settings to the USA on all my servers just to run the Get-SeupLogs.ps1 so I decided to have a look at the guts of the script.
I opened the Get-SetupLogs.ps1 script in a text editor – and found the following definition of the DataSet that is used to store the data when parsing the logs.
The line that I was interested in was:
I changed the line to look like the following:
In essence, rather than trying to parse any date value within the log file being processed to a DateTime it would be processed as a normal string.
After making this change the script ran correctly.
Now I don’t know if this is a problem that is peculiar to my own setups, or the script prefers a US based locale (there is nothing to suggest in the file that it does) – but if you should encounter this problem, the above is a workaround that can used.