Powershell DIY: Install Powershell!

Below is the requirements and links to Powershell installations!  Please remember to meet all of the requirements before attempting to install Powershell.

Workstation Operating Systems:

Version	Operating systems supported	Requirements
Powershell 1.0	- Windows XP - Windows Vista	-.NET Framework 2.0 - Windows XP Service Pack 2 or - Windows XP Service Pack 3
Powershell 2.0	- Windows XP SP3 - Windows Vista SP1 - Windows 7*	-Windows XP Service Pack 3 -.NET Framework 3.0 for Powershell 2.0 -.NET Framework 3.5 for Powershell 2.0 ISE
Powershell 3.0***	- Windows 7 SP1 - Windows 8**	- .NET Framework 4.0   Or -.NET Framework 4.5 - Management Framework 3.0

*Windows 7 has Powershell 2.0 and Powershell 2.0 ISE natively installed

**Windows 8 has Powershell 3.0 and Powershell 3.0 ISE natively installed

Server Operating Systems

*** Powershell comes in the Management Framework 3.0 package

Version	Operating systems supported	Requirements
Powershell 1.0	- Windows Server 2003 - Windows Server 2008****	-.NET Framework 2.0
Powershell 2.0	- Windows Server 2003 SP2 - Windows Server 2008 R2	- Windows Server 2003 SP2 -.NET Framework 3.0 for Powershell 2.0 -.NET Framework 3.5 for Powershell 2.0 ISE
Powershell 3.0***	- Windows Server 2008 SP1 - Windows Server 2008 R2 SP1 - Windows Server 2012	- Windows Server 2008 R2 SP1 - .NET Framework 4.0   Or -.NET Framework 4.5 - Management Framework 3.0

*** Powershell comes in the Management Framework 3.0 package

****Optional Feature

HISIMP! Announcement

As many of my readers may know I strive to learn more about the functionality of Powershell.  Recently after attending a presentation given by Ed Wilson on Powershell 3.0 best practices I was asked to write an article for his blog, Hey! Scripting Guy!  So on 4/13/2013 you will see my article on his blog!  I invite you all to view and leave your comments.

Powershell Script DIY: Creating Objects

An essential part of working with Powershell is the end result.  While it is all well and good to read the output on the screen with the write-output command, it’s easier to just dump it into a log or a text file for later analysis.   As usual we start with Set-Location:

Set-Location “c:\Temp”

I like to start by defining a variable that will act as a placeholder for this file name.  This has two advantages, it shortens the amount of text that is gunking up your script, and you will only need to change one string to effect the entire script should you choose to change the file name:

$foo = "foo.txt”

With the filename defined by a variable it is now time to actually create the file itself.  This is done with the New-Item command:

New-Item

The new Item’s name needs to be clearly defined directly after the command, and you must encapsulate it in quotations.  If you so choose, you can opt to just name the actual file name if you wish, Just replace the variable  “$foo” with “foo.txt.”:

                New-Item "$foo"

After you Define the file name the –itemType operator must be used to tell Powershell what exactly it is you want to create:

New-Item "$foo" –ItemType

As we are creating “foo.txt” It lends to reason that we would use the File object type:

New-Item "$foo" -itemType File

This is what your script should look like so far:

Set-Location “c:\Temp”
$foo = "foo.txt”
New-Item "$foo" -itemType File

With a few variations New-Item can also be used to create directories.  As with creating a file, we first define our variable:

                $FooFolder = “FooFiles”

And we use the  New-Item command to create the object:

                New-Item “$FooFolder”

Instead of using the File object type we use Directory:

                New-Item “$FooFolder” –ItemType Directory

Giving us this:

Set-Location “c:\Temp”
$FooFolder = “FooFiles”
New-Item “$FooFolder” –ItemType Directory

Amazing! The fundamentals are there to create your folder, and then create the file within the folder:

Set-Location “c:\Temp”
$FooFolder = “FooFiles”
New-Item “$FooFolder” –ItemType Directory

Set-Location $FooFolder
$foo = "foo.txt”
New-Item "$foo" -itemType File

As usual, Please provide me with feedback; we only learn by working together! Also a +1/Like/Tweet/LinkIn always helps

Sources: Myself

A word on standardization for this blog

Greetings!  I feel it is time for me to set down a set of standards for my blog so that none get confused.  I have renamed and reformatted all of my blog entries for the sake of standardization. 

11.       All Powershell specific posts will be labeled as “Powershell Script DYI” for Search Engine Optimization.

22.       All variables and filenames will be some variation of “Foo.”  “Foo” is an industry standard catch all term describing a generic file.  I use this for the sake of standardization

33.       All IP addresses will be 192.168.1.1 255.255.255.0.  This is so that if you do use my scripts, you do not accidentally get into a protected network.

44.       The folder we work out of will always be c:\Temp. 

55.       All usernames will be either John Reginald Doe or Jane Renee Doe

66.       All commands / code will be indented and Italicized and all variables/objects will be bolded.

Thank You & Have an excellent day!

Powershell Script DIY:Naming Conventions

Powershell Script DIY: Naming Conventions

Greetings and welcome to “Help! I’m stuck in my Powershell!”  Today we address an important issue that plagues all Powershell scripter’s: The dreaded “I have 44 different script files named some variation of "Foo.PS1!” A naming convention is a documented system of naming files, variables, folders,   ect.  Naming convention in a production environment is paramount as it helps reduce confusion when you have multiple scripts you are working on.  Here I will help you with a Simple naming convention for a file, a folder, and a script. But first, I will define what can, and cannot be used as an Object name in windows:

File / folder limitations & why they are in place:

/  and \	used for directory paths
? and *	Used as wildcards
< and  >	Used for system functions
:	Used to define a port when referencing a port location
|	Used to string commands together
“	Used to define a path or file that contains spaces
Any name over 255 characters long (Fat32) or 256 characters long (NTFS)	The maximum file name can only be 260 characters long, including extension.
Space at the end of a name	A space indicates a separation, while allowed inside a name it creates system conflicts at the end
Period at the end of a name	A period indicates a separation between the name and the extension
com1, com2, com3, com4, com5, com6, com7, com8, com9, lpt1, lpt2, lpt3, lpt4, lpt5, lpt6, lpt7, lpt8, lpt9, con, nul, and prn	Reserved by windows for system use
(Source: http://support.grouplogic.com/?p=1607)

Now that we have defined what you cannot do, let’s look at some of the things you can use in the naming convention:

Purpose	Computer name
Date	Server name
Time	Physical location
Version number	Group Name
Author	Data Source

FILE Naming Conventions:

When creating a file naming convention you must first define the intent of the file.  Our purpose is to house source data from our source “foo”:

Foosourcedata

I prefer to separate portions of my name with either – or _: 

Foosourcedata_

The source of our data is Server1:

Foosourcedata_Server1_

I like to include the date-time group:

Foosourcedata_Server1_01JAN2013_1200

And the important thing to add at the end is the extension.  An extension is not necessary for Powershell to pull data; rather it is useful for debugging.  I prefer to use the *.log for source data:

Foosourcedata_Server1_01JAN2013_1200.log

So we used “Intent_Source_Date_Time.extention” Remember, this is only an example, and you do not need to follow this example to the letter.

Folder Naming Conventions:

Folders are a slightly different case as their purpous and function are fundamentally different.  With that being said, instead of starting with “intent,” we will start with “contains.”  Defining what your folder contains is important, as it helps navigation to the files it contains.  This example will use “Foo source data files”:

Foo source data files

If this is a sub directory, you can append the group, or variable that differentiates those files contained within from the rest of the files:

Foo source data files_Server1

Additional items can be added at the end, but remember that the folder name should generally describe everything it contains.

Script Naming Conventions

As scripts are inherently files, they can be treated as such when naming them, with a few caveats:  The file name should start with its purpose and not what it contains, and you should always end it with a version number.  To start we will use fooscript to describe its purpose:

Fooscript

It is a good idea to follow this with the author’s initials if you are working in a multi-admin environment:

Fooscript_JRD

Instead of a date I prefer using a version number (I will explain more on this later on in the post):

Fooscript_JRD_1.0.1

If this is a work in progress you can append “Working” after this, while it is not required, it is a good idea if you work on a shared system, or the script resides on a network drive:

Fooscript_JRD_1.0.1_Working

Finally, you should append the extention particular to your scripting language.  We use Powershell here, so the extension is “*.PS1”:

Fooscript_JRD_1.0.1_Working.PS1

 The version number is an unofficial industry number that is delimited by periods used to identify the progress of the script.  Normally, there are 3 values:

1.2.3

The first number, “1” indicates major changes.  This should only change if there is an major revision to the code.  The second number, “2” refers to Incremental change.  This means an added minor feature, or changing out a block of code for a more effective block without fundamentally altering the function of the script.  The final number, “3” indicates a bug fix, i.e. if the script crashes under specific circumstances.

As always, I encourage commenting & sharing.  It does no one good if we keep knowledge and resources to our self! 

Sources: http://support.grouplogic.com/?p=1607

Powershell Script DIY: removing items based on date

Powershell Script DIY: removing items based on date

Warning: This DYI is potentially damaging, be absolutely sure you want to do this and you test it in a sandbox first.

With that being said, today we are going to remove items from a directory basted on their date.  The first thing we are going to do is define the directory.  We start with “dir”:

                Get-ChildItem

We need to define the location:

                Get-ChildItem 'C:\Temp\'

Now we use the –recurse operator.  Recurse is short for recursive which, plainly put means serch everything in subdirectories too.  So if you don’t want it to do this, skip this next step:

                Get-ChildItem 'C:\Temp\'-recurse 

Now that we have defined the scope of the commands, we need to use the pipe operator in order to tell it “now that you have gotten c:\Temp AND everything in every folder it contains do this”:

                Get-ChildItem 'C:\Temp\'-recurse  |

In order to diferenciate between files, we need to give Powershell a conditional statement.  We begin this with “where”:

                Get-ChildItem 'C:\Temp\'-recurse  | where

When you use a conditional statement, such as foreach-Item or Where, we need to encapsulate the statement itself in curley brackets {}:

                Get-ChildItem 'C:\Temp\'-recurse  | where {}

Because we want to remove old items we are going to use the get-date command:

                Get-ChildItem 'C:\Temp\'-recurse  | where {(get-date)}

We encapsulate this in parantheses as well in order to say that we are not getting the date from system time.  Next we define what date we want to get, which is the file creation time time:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime)

Remember the -$_. The – indicates what to get, the $_ indicates it is a list of items and the . belongs to .creationTime.  Moving along we encapsulated all of that within another set of parentheses to say that is a group that has a specific output, creation time. We need to then do something with it to indicate the length of time that has passed since it was created.  This is where we use .days:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime).days

Now here is where we accually select old items with the –ge operator.  Remember if the file was created today, then its age is 0.  For our purpouses we will say we want to select all files not created today:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime).days -ge 0

Now that we have selected the files that we want we need to add an additional command, which means an additional Pipe operator:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime).days -ge 0} |

Now because we want to remove we use the remove-item command, which was the same as del in DOS:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime).days -ge 0} | remove-item

Remove-Item has a couple of switches in it that you can use, for our purposes we are going to use the –force and the –recurse switches to tell it to delete EVERYTHING selected and to do it nondescrimitory:

                Get-ChildItem 'C:\Temp\'-recurse  | where { ((get-date)-$_.creationTime).days -ge 0} | remove-item -force –recurse

And there you have it!  As usual please add your comments below and I fully encourage you to share this with your colleagues.  Also that extra few clicks to +1, Like, Tweet, linkedin Goes a long way for me!

Sources: Microsoft Scripting guy http://preview.tinyurl.com/37ljrya, Myself

Powershell Script DIY: Use a Variable to Refer to a User System Folder

     One of the problems I run into when writing scripts is the confusion when addressing dynamic and system specific folders.  By dynamic folders, I mean the ones that are specific to each user such as the desktop, my documents, app data, ect.  As you may well know, I like to work with variables as they tend to simplify things when used properly.  We start by defining our variable with the "$":

$desktop =

Next we are going to tack on the [Environment] definition this is going to state that the value is indeed an environmental variable.

$desktop = [Environment]::

You may notice the :: after [Environment].  This is necessary to signify that we are going to specify a part of the environment, particularly, the path of the desktop directory.  We are going to do this with GetFolderPath.

$desktop = [Environment]::GetFolderPath

We now specify what variable, for our purposes we are of course gong to use the desktop.  This needs to be encapsulated in parentheses, and in double quotations to treat it like text.

$desktop = [Environment]::GetFolderPath("Desktop")

Now that you have the complete command, what exactly does it do? It starts by saying The Variable ($) Desktop is equal to (=) the Desktop Path ("Desktop") which you can get the path from (::GetFolderPath)

the working environment ([Envirment]).

This operation can be done using the following folders, and remember they must be typed exactly as you see here:

Desktop
Programs
Personal
MyDocuments
Favorites
Startup
Recent
SendTo
StartMenu
MyMusic
DesktopDirectory
MyComputer
Templates
ApplicationData
LocalApplicationData
InternetCache
Cookies
History
CommonApplicationData
System
ProgramFiles
MyPictures
CommonProgramFiles

As always I fully encourage comments.  There is always a better way to do something