PowerShell:Get-Date Cmdlet

Posted by Kris Powell

Aug 7, 2014 1:26:00 PM

Today, I’d like to make use of an awesome PowerShell cmdlet, Get-Date. Get-Date as the name implies, gets the current date and time and use the results for other cmdlets. Get-Date by itself will return the current date.

powershell get date

We can manipulate this result a handful of ways to make the date into a format that’s more useful to our needs.

We can use -Format to view the date any just about any date format that we can imagine.

powershell get date change format

Here is a great link for which format patterns you can use - http://ss64.com/ps/syntax-dateformats.html

In addition to formatting the date to whatever format suits you best, there are also methods you can use to manipulate the date itself (not just the formatting).

In this example, we can see what day it will be a week from now:

powershell get date manipulate date

Here's a quick list of methods you can use to modify Get-Date:

  • AddDays
  • AddHours
  • AddMilliseconds
  • AddMinutes
  • AddMonths
  • AddSeconds
  • AddTicks
  • AddYears

We can make use of Get-Date and these methods in our scripts to do fancy things like finding all files that have been created within the last 30 days.  We can even take that result and process it to remove the files that are found.

#############################################################################
#   Find files older than 30 days 
#############################################################################

$time = (Get-Date).AddDays(-30)
$path = "C:\temp"

Get-ChildItem -Path $path -Recurse -Force | `
 Where-Object {$_.LastWriteTime -lt $time }

#############################################################################
#   Find files older than 30 days and DELETE
#   Please excercise caution. There is no undo to this action
#############################################################################

$time = (Get-Date).AddDays(-30)
$path = "C:\temp"

Get-ChildItem -Path $path -Recurse -Force | `
 Where-Object {$_.LastWriteTime -lt $time } | `
 Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
Read More

Topics: powershell

Powershell: Searching Through Files for Matching Strings

Posted by Kris Powell

Jul 31, 2014 12:51:00 PM

 

kris-151

It can be very time-consuming and tedious to sift through many files. Unless you’re a fan of working over a weekend and opening file after file while being slumped in a chair, then I would suggest making use of the information from today’s Powershell blog post!

Consider a directory, “C:\Temp” with many text files created. Each of the files has random text data inside. We’re looking for only the files that contain one particular string. Additionally, since we don’t know how many matches we are going to find, we’re going to create an array to store the found matches.

In order to search for strings or string patterns, we’re going to use the cmdlet Select-String.

###########################################################

$Path = "C:\temp"
$Text = "This is the data that I am looking for"
$PathArray = @()
$Results = "C:\temp\test.txt"

# This code snippet gets all the files in $Path that end in ".txt".
Get-ChildItem $Path -Filter "*.txt" |
   Where-Object { $_.Attributes -ne "Directory"} |
      ForEach-Object {
         If (Get-Content $_.FullName | Select-String -Pattern $Text) {
            $PathArray += $_.FullName
            $PathArray += $_.FullName
         }
      }
Write-Host "Contents of ArrayPath:"
$PathArray | ForEach-Object {$_}


##########################################################

Here’s the breakdown:

This will search the directory $Path for any items that include “.txt” in their names and that are not directories.

Get-ChildItem $Path -Filter "*.txt" | 
   Where-Object { $_.Attributes -ne "Directory"}

For every match it finds, it will check the contents of the match using Get-Content and verify any matches with $Text by using Select-String. If it finds a match, it puts the full name of the match into the $PathArray array.

      ForEach-Object { 
         If (Get-Content $_.FullName | Select-String -Pattern $Text) {
            $PathArray += $_.FullName
            $PathArray += $_.FullName
         }
      }

There you have it.

Bonus options
Exporting results to file:

If you want to export that all to a file instead of on the screen, then simply pipe it into an Out-File cmdlet. For example:

$PathArray | % {$_} | Out-File “C:\Some Folder\Some File.txt”

Searching through all subfolders:

If you want to search all subfolders for additional *.txt files as well, then add “-recurse” to the original Get-ChildItem command:

Get-ChildItem $Path -Filter "*.txt" -Recurse

 
Read More

Topics: powershell

Powershell: How to Write Your First Powershell Script

Posted by Kris Powell

Jul 17, 2014 1:32:00 PM

“I love spending twice as long and working twice as hard to get half as much done!”  – Nobody ever.kris-151

Everybody loves shortcuts and time savers.  I think this goes twofold for the aggravation that comes with managing computers.

Enter Powershell!

Though there are many great scripting languages out there, we're going to spend our time with Powershell. If you're using a recent version of Microsoft Windows, you've even probably already got a version of it installed.  

Powershell saves scripts in the .ps1 format.  I have created both a file and a folder for our demonstration - C:\Scripts\My First Script.ps1 - but please feel free to use your own custom folder and filenames.

Edit your file and add the following line:

Write-Host “Hello, World!”

Save the file and return to the Powershell window. In order to run the script, the most common method is by calling it:

& “C:\Scripts\My First Script.ps1”

Go ahead and try that command.  You should get an error that says scripts have been disabled on your system.

This is normal behavior. In order to prevent malicious scripts from running on your system, Powershell enforces an execution policy.  There are 4 execution policies you can use:

  • Restricted – Scripts won't run.  Period. (Default setting)

  • RemoteSigned – Locally-created scripts will run. Scripts that were created on another machine will not run unless they are signed by a trusted publisher.

  • AllSigned – Scripts will only run if signed by a trusted publisher (including locally-created scripts).

  • Unrestricted – All scripts will run regardless of who created them and whether or not they are signed.

In order to use our newly-created script, we will have to modify our execution policy to allow our script to run.  Since we have not digitally signed our new script, our options for setting the execution policy are left to “RemoteSigned” and “Unrestricted.”  We are going to change it to RemoteSigned.

In order to change the execution policy, we will need to reopen Powershell as an Administrator (the command will fail otherwise) and run the following command:

Set-ExecutionPolicy RemoteSigned

It will ask to verify that you really want to change the execution policy. Go ahead and select Y for yes, then go ahead and close and reopen your Powershell window.

After restarting the Powershell window, go ahead and try running that script again 

& “C:\Scripts\My First Script.ps1”

It should write back, “Hello, World!” to the window:

Congratulations!  You just wrote your first script for Powershell!    

As this blog series continues, we'll continue to add more helpful tips on how to use Powershell.  In the meantime, you know have the amazing power to create and run your own scripts.

Tune in next week for more scripting adventures.


Read More

Topics: powershell

Random Grunts on the Sys Admin Scene

Posted by Shane Corellian

Jan 26, 2011 1:00:00 AM

Shane Corellian Raindog Sys Admin
Photo by Helen Rosemier

I came across a pretty good YouTube channel featuring PowerShell videos. I haven't finished with all of the videos yet but I dig this guy's (Don's) style. I wish the video examples were a little more magnified sometimes but otherwise I'm quite pleased. Definitely check them out.

When you have an obvious language barrier with someone you work with never, EVER, listen to them and just nod your head. In fact when you don't understand a damn word they're saying, violently shake your head and mutter "oh, HELL no". You'll thank me.

If you're getting ready to add a feature to a script or a program make sure to ask yourself this question: What is the real benefit I get from adding this feature? Seriously? If you can't come up with a semi-literate answer, scrap it. Toss it. Move on. You'll thank me.

Sluffing. Hookey. Skipping. Truant. What did you call it when you missed school? Remember how you'd get in trouble for missing that class or even the entire day of school? Well try sluffing a meeting or two at work. If there are more than 6 people in regular attendance at your meeting, skip one every now and then. If there are more than 15 people then count your blessings and have your make to miss ratio come in around 1:5. You'll thank me.

I don't understand why so many computer geeks get upset at how our industry is portrayed in movies. Let the beliefs live on. I'm happy that my family thinks I can create a network connection between my mac and the aliens that are on the way down to earth. I finally look a little cool. I'm pleased that my extended family all think that I can blow crap up by just hitting a few keys on the keyboard. It keeps them in enough awe that I can cut in line to get the best Bratwursts and potato salad at every reunion. Just sayin' is all.


Follow me on Twitter @ShaneCorellian
Read More

Topics: random musings, humor, powershell

Deploy PowerShell 2.0: Distribute to your PCs with PDQ Deploy

Posted by Shane Corellian

Dec 15, 2010 1:47:00 AM

Shane Corellian Raindog Sys Admin
Photo by Helen Rosemier

OK, if you don't have PowerShell 2.0 on your Windows computers it's time to gird up your loins and just do it.

Thankfully, PowerShell comes included with Windows 7 and Server 2008 R2. For your other Windows OSes go grab the appropriate install file. If you don't already use PDQ Deploy for your simple software deployment needs then grab a free copy right here.

It's quite simple to deploy, actually. Just grab the installer file appropriate for your target OS create a deployment in PDQ Deploy

Below is a screenshot of a basic Installation of Windows PowerShell 2.0 for Vista/2008 32-bit computers.

blog spc 20101215 PowerShellInstaller

PowerShell is here to stay and it is a great shell which is something that Windows has been lacking for a long time. I remember when I first started playing with PowerShell back in 2007 I was hooked. For Windows Sys Admins this is a must-use technology.

We are going to add the ability to run PowerShell scripts natively from PDQ Deploy. So get PowerShell 2.0 on your targets systems sooner rather than later... perhaps the slow holiday season perhaps?


Follow me on Twitter @ShaneCorellian
Read More

Topics: install software remotely, pdq deploy, powershell, Microsoft Windows, remote software deployment

Top 10 Rejected Names for PowerShell

Posted by Adam Ruth

Oct 8, 2010 1:00:00 AM

 
What's in a Name?
    Photo by chigmaroff

We in the system administration community have become used to the name PowerShell. I know I have (I write about it often enough.) The name projects an important image. The image of being Powerful and also... I guess... being a Shell. As is so often the case, one must wonder if the product gives meaning to the name or does the name give meaning to the product. Does "Rolls Royce" bring to mind quality because of workmanship or is the name just a great fit? Well, you be the judge as you consider the top 10 names considered and rejected for PowerShell. One thing we can all agree on is that we're glad Microsoft made the choice they did.

10. AlmostBash

9. YAALShell (Yet Another Admin Language)

8. Cmd#

7. ClippyShell

6. Cmdlet Runner And Processor

5. VBScriptWho?

4. HunkyShell

3. LinuxShminux

2. Microsoft Interactive Keyboard Command Line Interpreter Client Console And Dynamic Script Processor 2008 Version 1 (Release 2)

1. DOS 7

Read More

Topics: humor, powershell

6 Missing PowerShell Cmdlets

Posted by Adam Ruth

Oct 1, 2010 1:00:00 AM

  
Something's missingPowerShell 2.0 shipped back in 2009 and included over 100 new cmdlets including major new functionality such as Jobs, Modules, and Remoting. That's great to see, but there's still so much more that can be done. So, in the vein of demanding others to do things for me, here are the top 6* cmdlets that PowerShell should ship with. 

Threaten-Process: For when you want to keep a process from getting out of line but aren't quite to the point that you want to kill it. Alias: taze

Delete-FileForever: Not only deletes a file, but prevents it from ever being re-created. Pretty handy when dealing with viruses or playing pranks on co-workers. Optional argument -past goes back in time and stops the file from originally being created (the Sarah Connor option.) 

Convert-RegistryToIni: Removes the registry completely from the system and replaces it with hundreds of .ini files in the Windows directory. Alias: out-of-the-fryingpan

Set-UACAutoClick: Creates a process to automatically click the accept button on all UAC prompts. For the wishy-washy person that's too scared to disable UAC but wants to get rid of the inconvenience (usually an MBA.) Alias: miss-the-point

Enable-FullSpeed: Makes the processor run at its actual speed, not the speed that's been imposed by the Trilateral Commission to keep the masses from decrypting secret government communications embedded in lolcats. Requires the tinfoil hat extensions. 

Set-MovieInterface: Changes the UI to have really large text, make a clicking sound whenever a character is typed, add unnecessary maps and graphics to search functions, and the ability to extract gigabytes of image data from half an pixel. Alias: fakeintosh


* The list is limited to only the top 6 because there isn't a Finish-MyBlogPost cmdlet. Oh, I guess it's really a top 7 list.

Read More

Topics: humor, powershell

PowerShell Tip: Default Parameter Values

Posted by Adam Ruth

Sep 17, 2010 7:23:00 AM

Default parameter?  I don't get it either.
    Photo by nineball2727

If you've spent any time working with PowerShell you've probably built a function or two. Function parameters are a handy way to make general purpose functions that can be used in a number of different ways. Consider, for example, that you have a function that restarts a service that, for whatever reason, is misbehaving. You could have this:

function RestartService($name) {
net stop $name
net start $name
}

Sometimes you need to add a sleep between the start and stop to make sure that the service comes back up correctly, but you don't want to make a new function (one that sleeps and one that doesn't) so you add a new parameter.

function RestartService($name, $sleep) {
net stop $name
sleep $sleep
net start $name
}

This works great, except now you have to pass in a 0 most of the time, and only use the sleep parameter on those rare occasions. To fix this, you can make the $sleep parameter default to 0 so that if you omit it you don't get a sleep.

function RestartService($name, $sleep = 0) {
net stop $name
sleep $sleep
net start $name
}

This will give you the flexibility you need.

# Don't sleep
RestartService SomeService 
# Sleep for 10 seconds before restarting
RestartService SomeService 10
Read More

Topics: windows administrators, windows administrator tools, powershell

PowerShell Tips for System Administrators: Format Views

Posted by Adam Ruth

Aug 23, 2010 1:00:00 AM

 
Amazing View
Photo by Dave_B_

In two recent posts I went over the PowerShell formatting cmdlets and calculated properties. Today I'm going to cover Views. You'll notice that when you display a normal object (such as the built-in FileInfo objects when you run dir) you don't see all of its properties. This is because PowerShell is using a View, which is selected based on the type of object you're outputting and which type of output is being used (table, list, or wide.)

The views are stored in XML files in the PowerShell directory which you can examine to see how the formatting is being performed. Not only that but you can add your own views and even override the default views used by PowerShell.

The standard views are stored in %systemroot%\System32\WindowsPowerShell\v1.0 in a files with the extension format.ps1xml. There are several files, but the one we'll be looking at is FileSystem.format.ps1xml. This file holds the formatting for the various file system objects, such as FileInfo and DirectoryInfo.  The section that defines the normal file system table output is this:

<View>
  <Name>children</Name>
  <ViewSelectedBy>
    <SelectionSetName>FileSystemTypes</SelectionSetName>
  </ViewSelectedBy>
  <GroupBy>
    <PropertyName>PSParentPath</PropertyName>
    <CustomControlName>FileSystemTypes-GroupingFormat</CustomControlName>
  </GroupBy>
  <TableControl>
    <TableHeaders>
      <TableColumnHeader>
        <Label>Mode</Label>
        <Width>7</Width>
        <Alignment>left</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>LastWriteTime</Label>
        <Width>25</Width>
        <Alignment>right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader>
        <Label>Length</Label>
        <Width>10</Width>
        <Alignment>right</Alignment>
      </TableColumnHeader>
      <TableColumnHeader/>
    </TableHeaders>
    <TableRowEntries>
      <TableRowEntry>
        <Wrap/>
        <TableColumnItems>
          <TableColumnItem>
            <PropertyName>Mode</PropertyName>
          </TableColumnItem>
          <TableColumnItem>
            <ScriptBlock>
              [String]::Format("{0,10}  {1,8}", $_.LastWriteTime.ToString("d"), $_.LastWriteTime.ToString("t"))
            </ScriptBlock>
          </TableColumnItem>
          <TableColumnItem>
            <PropertyName>Length</PropertyName>
          </TableColumnItem>
          <TableColumnItem>
            <PropertyName>Name</PropertyName>
          </TableColumnItem>
        </TableColumnItems>
      </TableRowEntry>
    </TableRowEntries>
  </TableControl>
</View>

If you're not used to XML this may appear a bit daunting, but you can get a quick sense of how it works. There are four main sections of the file.

  1. <ViewSelectedBy> indicates which object types are used by this view. In this case, the name FileSystemTypes refers to another section in the file that lists the types. That section is <SelectionSets>. The individual type names can be listed instead, but this reference makes the code shorter.
  2. <GroupBy> tells the table of files to be grouped by thier parent path. This also refers to another section of the file called <Controls>.
  3. <TableHeaders> sets up not only the titles that appear on the table columns, but also their width and alignment.
  4. <TableRowEntry> the actual values to show in the table. Three of the colums just pull out a property by name, but the LastModifiedTime uses PowerShell code to format the date in a particular way. Any PowerShell code can be used which gives a great deal of flexibility.

There are a lot of possibilities for how to create views and the documentation is a bit limited. To learn about formatting it's best to look at the included format files to see how things are done.

To make a custom view you will need to create your own format.ps1xml files since you can't edit the built in ones. If there is more than one view for an object then the first one found will be used. Otherwise they can be selected by name using the -View parameter of the format cmdlets. Once you have a file created you import the formats using the Format-UpdateData cmdlet. As an example of a new format, I've create a format file that adds a CreationTime column in addition to LastWriteTime. Download the file, save it with the extension .format.ps1xml and run the following command:

Format-UpdateData -PrependPath [filename]

Now when you list the contents of a directory you will see the new column. Alternately you could have used -AppendPath to put the file after the built in formats and then you would need to use the view by name:

dir | Format-Table -View MyFormat

To make the custom format persistent between sessions, add the Format-UpdateData command to your PowerShell profile. One of the principles of PowerShell is the ability for you to configure it to your tastes and Views are a very powerful, if somewhat complex, way to get just want you want.


Need help using formats (or anything else) in PowerShell? Post a question in our PowerShell forum to ask one of our engineers.
Read More

Topics: windows administrators, windows administrator tools, powershell

PowerShell Tips for System Administrators: Profiles

Posted by Adam Ruth

Aug 2, 2010 1:00:00 AM

 
Sphinx Profile
Photo by Andrew®

A profile in PowerShell is nothing more than a script file that is run when the shell starts. This file is very handy to create variables, functions, or change settings that you find you use a lot. Instead of having to re-import a library of functions or change the shell's settings each time you start up PowerShell.

The variable $profile holds the name of the file that you are using for the current shell. PowerShell doesn't create this file, so it won't exist out of the box, but the variable will still hold the name. For example, on my box it is:

C:\Users\Adam> $profile
C:\Users\Adam\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

You can put anything in this file that you can put into a script file, so feel free to create functions, set variables and run commands. Any changes made to the file won't be used by the current shell, so you'll need to restart to see any effect. And remember that if you are going to load any other script files in the profile you need to precede the script with a single dot (.) for the functions and variables in that script file to remain visible in your new shell:

. \libs\Functions.ps1

There is also a profile on the computer that applies to all users as well as profiles for other shells. Microsoft has all of the lowdown.


Follow me on Twitter @AdamRuth

Read More

Topics: windows administrator tools, powershell, tips

Admin Arsenal Blog

Subscribe to Email Updates