PowerShell has great functionality for working with csv files. They make an excellent way of saving information generated by PowerShell - for instance
Get-Process | Export-Csv data.csv -NoTypeInformation
Having created a csv file how can we read it? It is possible to use Notepad but then the columns are not padded to the same width so the data can appear jumbled. Ideally we would want to use an application that generated a grid view - like excel.
Excel is very easy to use for this
$xl = New-Object -comobject "excel.application"
$xl.visible = $true
Create an object for the Excel application. Open the csv file in a workbook and make it visible.
Is there a difference between scripting and automation. According to Dan http://blogs.msdn.com/dtjones/archive/2008/11/23/scripting-dba-actions.aspx the answer is yes. Scripting means you perform a task programmatically using a scripting language (PowerShell I hope). Automation means that the script is automatically initiated as a scheduled task or a SQL Server job etc.
A quick search shows a number of definitions for automation:
"The replacement of manual operations by computerized methods."
"The automatic operation or control of equipment, a process, or a system."
"a system in which a workplace or process has been converted to one that replaces or minimizes human labor with mechanical or electronic equipment"
I would argue that there is a spectrum of activity ranging over:
- perform task manually (GUI or command line)
- script task
- run script automatically
Creating 7000 users and mailboxes in AD\Exchange is something you would do with a script. Would you have that script automatically initiated - I don't think so. But I would argue that you are still automating that task. The machine is doing the work - quicker and potentially (hopefully) more accurately.
My stance is that scripting is automation and whether you run the script manually or automatically in response to a task you are still automating.
There are some useful guidelines on scripting in the post that are applicable to any language.
Want to learn more about how PowerGUI came about and where its going - then listen to the latest get-scripting podcast at http://get-scripting.blogspot.com/2008/11/get-scripting-podcast-episode-5-dmitry.html
I was working with an Exchange 2007 system today - using Get-StorageGroupCopyStatus. One of the things I was interested in was the logs that had been generated, replicated and replayed. Exchange 2007 uses 1 MB log files and the file names are based on incrementing numbers - hexadecimal numbers (base 16). Unfortunately Get-StorageCopyStatus reports the log numbers in decimal (base 10).
I can't convert numbers in the thousands, or greater, easily between decimal and hexadecimal. So I use a conversion routine that is based on this:
Convert the integer to a string and at the same time convert to base 16 (hexadecimal). At the same time convert to upper case to make it match the log numbers.
This can be used as the basis of the expression in a calculated field used in format-table or a select statement. That bit I will leave as an exercise for the interested student of PowerShell
Another question from the webcast concerned testing for the existence of an OU if you know its distinguished name. It turns out that the System.DirectoryServices.DirectoryEntry class has an Exits method that can be used for testing in this way.
One thing to be careful of is that it is a static method so you don't actually create an instance of the object. You can use it as shown below.
It even works with the [adsi] shortcut.
Another useful piece of AD scripting functionality. Makes testing for the existence of objects much easier when creating users etc.
One of the questions on the AD webcast I've just finished was about administering DHCP with PowerShell. As far as I am aware there isn't an interface available through .NET, WMI or COM that enables us to administer DHCP servers through PowerShell.
If you know differently I would be grateful for some examples and pointers to the documentation.
In my post on PowerShell Objects - http://richardsiddaway.spaces.live.com/blog/cns!43CFA46A74CF3E96!1875.entry - I mentioned Tee-Object and gave an example. Mats left me a message asking why Tee and asking did it mean temporary.
I had always looked at it as a branching - much like a T join in pipes. The help file says "The Tee-Object cmdlet send the output of a command in two directions (like the letter T). "
Think of it as a dead end branch off the pipeline.
The regular expressions in my previous post should have been
PS> "Richard" -match "R.*
PS> "Richard" -match "[A-Z].*"
PS> "Richard" -match "[R][ic]+.*"
The * of a wildcard has to be replaced by .* which means any character except a new line any number of times including zero.
Thanks to Jaykul for pointing out the error
Lets start with confession time. Regular expressions are something I have tended to avoid like the plague. Why? I suppose its because I've never taken the time to understand them. Having seen some of the powerful things that can be done with them (and the fact that I've promised to talk about them at a UG meeting ) its time to dig into them. They become incredibly useful with select-string and switch statements as we will see later.
From the conversations I've had there are a lot of people who feel the same way about regular expressions. Hopefully we can uncover some of the mystery.
We all seen or used something like this
PS> "Richard" -like "r*"
This is using a -like operator on a wildcard match. The PowerShell wildcards are * for zero or more characters, ? for a single character and  to match a range or specified characters for example:
PS> "Richard" -like "[A-Z]*"
PS> "Richard" -like "R[ic][ic]*"
While not counted as regular expressions wildcard matches can be thought of as the lead in to regular expressions. The first difference is that we use -match instead of -like.
So to duplicate what we have seen so far we would use
PS> "Richard" -match "R."
PS> "Richard" -match "[A-Z]."
PS> "Richard" -match "[R][ic]+."
In the first example we are just replacing the * of the wildcard with the regular expression . which means any character except a new line. The second example has a match against a letter in the range A-Z and the third is looking for an "R" then either an i or a c twice (the + sign means one or more matches)
We have seen how regular expressions build on wildcard matching. Next time we'll dive a bit deeper in regular expressions.
When I'm talking, or writing, about PowerShell I often refer to your four friends when you are first learning PowerShell. These are:
Between them you can discover a vast amount of information about how PowerShell works. if you are new to PowerShell I would strongly recommend getting to know these four cmdlets very well. The time will be amply repaid.
There may be a new kid on the block to join these four. Jeffrey Snover has posted a script on the PowerShell team blog to display the cmdlets in a particular snapin as a chart based on verb and noun. http://blogs.msdn.com/powershell/archive/2008/11/22/verbs-vs-nouns-by-snapin.aspx
This is very useful.