Going on a Get-Date…part 2

As mentioned previously in my first part of this Get-Date series, I had run into some issues that were seemingly easy to resolve, yet proved to be a bit more hassle than expected.

Funny enough, the second issue where I ran into date issues was just a day or so apart from the first, so I thought I’d resolve my issues with the knowledge I had obtained previously.

The Problem

I had received an Excel sheet which contained various information, one column being Warranty dates.
Now the issue was that the Excel sheet was generated on a system which had NL-NL Culture configuration, while my machine is running on EN-US configuration.

The reason this is important is because NL-NL has dates sorted as follows:

while EN-US has this configuration:

which means Excel doesn’t recognize the input as dates and formats the cell as general or in some cases even as text.

Take for example 02/07/2012.
NL-NL would say this is 2 July 2012, while EN-US says this is 7 February 2012.

But in the case of for example 24/11/2010 NL-NL would say 24 November 2010 and EN-US would just flip, because that simply can’t be a date format.

The Struggle

When trying to manipulate the data through PowerShell I was running into issues..

Ok, so I needed to convert this to a DateTime object.. let’s give this a shot!

Ah, crap, that was not what I needed…

Let’s use the tips give on my previous issue

Ok, this was not the way to go.. I need to specify which format my date will be in, so that it can be parsed correctly.

So close, yet so far away…

Using my best friend in situations like this, I tracked down the following site which gave excellent examples on how to resolve issues like this.
I first had to define the template format I was using and then parse my input using said template.

Grrrrr, this is becoming annoying!

Browsing more information on the .NET DateTime Parse and ParseExact Methods provided me with some insight on how it should work, but still I was getting the same error message as before.

It was time to call for help… it had to be something simple, but I was not getting the outcome as expected.

The Solution

How simple can it be… ūüôĀ

Again the major issue here is PROPERLY reading what is required.. the answer was right in front of me

Help again came through the FaceBook PowerShell group, and in this case by my local DuPSUG founder and PowerShell MVP Jeff Wouters :

The template format I had defined earlier was incorrect!

Should be:

Besides that, while the earlier site had mentioned using $null as format provider, but best is to define this properly:

Technical info on [System.Globalization.CultureInfo]::InvariantCulture can be found here, but the best short and readable description I could find was:

The CultureInfo.InvariantCulture property is used if you are formatting or parsing a string that should be parseable by a piece of software independent of the user’s local settings.

Now I can simply display the dates in the correct format and now I see that Excel correctly sees the input as Dates and I can finally sort as wanted!

 

Happy Scripting! ūüôā

twitterredditlinkedinmail

Going on a Get-Date…part 1

Simple issues, simple solutions?

Recently I’ve been doing quite some break-fix cases, which didn’t quite make blogging a high priority.

It did on occasion provide me with nice little gems that I decided to spend a little personal time on, because I thought it would be better to force myself to use PowerShell instead of resolving things manually or through a GUI.
Also, I thought these issues¬†would be “simple, quick solutions”, which turned out to be a bit too optimistic.

Looking back, the extra effort spent on these issues will most probably pay me back in the not too long future, because I have the feeling I’ll re-use the concepts again.

Enough chit-chat, on to the issues!

Problem #1

Fairly simple issue really, I had created some temporary Virtual Machines to see if my MDT solution was working properly, and I had removed the Virtual Machines from Hyper-V manager to clean up again.

Unfortunately, this did not remove my Virtual Hard disks, which is actually what I really wanted [because honestly, who cares about the 10kb .XML when you have a 10GB .VHDX gathering dust].

I went to my VHD folder and listed all my disk files:

Great, now I had a list of all the disk files.
I however only needed to have a list of the disk files that were created today, because these were the disks for the temporary VM’s

Simple right?

Awesome, the files were listed once more.
But wait… this is nice, but ideally I wouldn’t have to tell the system what day it is today.

Since I know I can easily get the current date using

I thought I was able to solve my “issue” with the following command

Of course too simple of a thought.. ¬†the output from Get-Date looks nothing like the input I need…

I was trying to figure out how I could get it to display the results I needed.

A quick glance at

surely provided me with the way to go!

Unfortunately this didn’t work, even though it gave me the exact same result as me manually entering the date in a string… or did it…
It turned out I didn’t read the output properly and instead of 26/1/2016 it gave me 26/01/2016 instead, which is almost like the date I needed, just not quite…at all…

Now believe me when I say that now that I know the solutions that it’s “easy” to fix, but reading properly is basically most of the work…

Solution

Instead of using UFormat, using Format, but with the proper format switch, resolved my issue

Looking at how Get-Date should be used, brought me to the following MSDN link

It’s all about the formatting!
So, what it all boils down to:

Do note that while many things in PowerShell aren’t case sensitive, formatting rules ARE!

But wait, there’s more…

Great tip from your friendly neighbourhood PowerShell-Man also provided me with an alternative solution, which uses the [DateTime] type accelerator to generate a .NET framework System.Globalization.DateTimeFormatInfo object.

While I already found the solution, this tip would come handy quite soon… but more on that in part 2!

 

twitterredditlinkedinmail

Scheduled Tasks – PowerShell Scripts with Parameters

Perhaps a very “simple” issue, but I noticed that when looking for this it took me longer than expected to find the result I had in mind.

The issue at hand

I  have a script which requires various parameters to be provided so that I can run it.
When running the command through an active console session it would look like this:

As you can see, this can be quite the pain,  but if I get this configured properly can re-use this at various customers.

The solution

Now I won’t bore you with all the Scheduled Tasks Wizard screen, as there is only 1 screen that’s important for all of this:
The Start a Program screen

What you need to fill in to make sure you get PowerShell to run the script you require, using the parameters you want it to use.

  • Program/Script
    Full path to PowerShell executable [while some people have gotten it to work with just PowerShell, this should ALWAYS work]
  • Add arguments (optional)

    for example
  • Start in (optional)
    Not required

That’s it!

Extra Tip

While this should be all that’s required to make sure it runs properly, I found a tip that might prove quite useful when troubleshooting issues with Scheduled Tasks:

In the Add arguments (optional) section, if you add

after your full script path + parameters, it will properly include the last exit code under the Last Run Results column, making troubleshooting that much easier.

 

Happy scripting ūüôā

 

twitterredditlinkedinmail