Search results for 'app:weblogs' matching tags 'Weekend Scripter' and 'guest blogger'

Weekend Scripter: Use PowerShell to Upload a New File Version to SharePoint

Anonymous — Sun, 28 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVP, Niklas Goude, talks about using Windows PowerShell to upload a new version of a file to SharePoint.

Microsoft Scripting Guy, Ed Wilson, is here. Today Niklas Goude is our guest blogger. You can read more from Niklas in his past Hey, Scripting Guy! Blog posts.

Take it away Niklas…

In a previous post, Use PowerShell Cmdlets to Manage SharePoint Document Libraries, we talked about uploading files to a share in SharePoint 2010. Now we'll take this a step further and update a minor or a major version of an existing document.

Here’s a quick recap of the code used to upload the file:

# Add the Snapin
Add-PSSnapin Microsoft.SharePoint.PowerShell

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Get the file on Disk that we want to upload
$file = Get-Item C:\Documents\MyDoc.docx

# upload the file.
$spFolder.Files.Add("Shared Documents/MyDoc.docx",$file.OpenRead(),$false)

What we’ve done so far is to upload a single document to a document library in SharePoint 2010. The file used in this example is stored on drive C:

The document contains a single line:

After we run the Windows PowerShell code, the document gets uploaded to a document library in SharePoint 2010.

We can check the versioning for the document by clicking Version History in SharePoint:

We’ll see that the version number is set to 0.1:

Now, let’s open the file that is stored on drive C and modify it:

Back in Windows PowerShell, we use SPFileCollection to pick up the document we just uploaded. In this example, we are going to filter out the document where the name is equal to MyDoc.docx by using the Where-Object cmdlet.

# Retrieve specific Site
$spWeb = Get-SPWeb http://SP01

# Create instance of Folder
$spFolder = $spWeb.GetFolder("Shared Documents")

# Retrieve a Specific File.
$spFile = $spFolder.Files | Where-Object { $_.Name -eq "MyDoc.docx" }

We pick up the file because we want to use some of its properties for the new version that we want to upload. When we upload a new version of the document, we still use the Add method that is provided by the Microsoft.SharePoint.SPFileCollection, but with a different overload definition. Here’s the definition on MSDN: SPFileCollection.Add method (String, Stream, SPUser, SPUser, DateTime, DateTime).

The parameters we want to use are: urlOfFile, File, CreatedBy, ModifiedBy, TimeCreated, and TimeLastModified.

We can get the following values from the existing document in SharePoint 2010: UrlOfFile, CreatedBy, ModifiedBy, and TimeCreated. We can get File by using Get-Item, and we can get TimeLastModified by simply using Get-Date.

First, let’s get the modified MyDoc.docx from drive C:

$file = Get-Item C:\Documents\MyDoc.docx

Next we run the method:

$newVersion = $spFolder.Files.Add($spFile.Name, $file.OpenRead(), $spFile.Author, $spFile.ModifiedBy, $spFile.TimeCreated, (Get-Date))

If we open the SharePoint document library again, we’ll see that we have a new minor version of our document, .02.

And finally, if we want to add the modified document as a major version, we use the Publish method:

$newVersion.Publish("")

Now we have a new major version, 1.0, instead.

~Niklas

Thank you, Niklas, for taking your time to share your knowledge.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Improve Performance When Combining PowerShell Arrays

Anonymous — Sat, 27 Apr 2013 05:00:00 GMT

Summary: Microsoft premier field engineer, Chris Wu, talks about combining Windows PowerShell arrays.

Microsoft Scripting Guy, Ed Wilson, is here. Chris Wu, a Microsoft PFE, is back to share his knowledge. See previous Hey, Scripting Guy! Blog guest posts from Chris.

Here is contact information for Chris:

Twitter: https://twitter.com/chwu_ms
Facebook: https://www.facebook.com/mschwu
LinkedIn: http://ca.linkedin.com/in/mschwu

Take it away Chris…

While teaching a Windows PowerShell workshop, I was asked about how to combine two arrays of different objects (which share one key property) into one that contains objects with properties from both source objects. One real world scenario is to merge information retrieved from Active Directory (a list of Active Directory users and their properties) and Exchange Server (mailboxes).

The current approach by the student is to use two-level loops, which has seen performance issues when source arrays become huge in size (the following code snippet uses dummy data for demonstration purposes).

$ADList = @"

chwu,chwu@microsoft.com,Chris Wu

tst1,,Test User1

tst2,tst2@contoso.com,Test User2

"@ | ConvertFrom-Csv -Header Name,mail,CN

$EXList = @"

chwu,ex1.contoso.com

tst2,ex2.contoso.com

"@ | ConvertFrom-Csv -Header Name,MailServer

$Result = @()

foreach($ad in $ADList) {

$Match = $false

foreach($ex in $EXList) {

if ($ad.Name -eq $ex.Name) {

$Result += New-Object PSObject -Property @{Name=$ad.Name; mail=$ad.mail; CN=$ad.CN; MailServer=$ex.MailServer}

$Match = $true

}

if(-not $Match) {

$Result += New-Object PSObject -Property @{Name=$ad.Name; mail=$ad.mail; CN=$ad.CN}

}

In this post, I will explore several options to improve the performance and cleanness of this code snippet.

The first thing we can do is remove the use of the $Result array, which has two drawbacks:

Every assignment operation will create a new array in memory with data copied from the source, which is inefficient.
It defeats the streaming benefit of the WindowsPowerShell pipeline because it returns all objects as a whole at the end of the processing. A best practice in Windows PowerShell is to emit an individual object whenever it’s ready.

Another performance issue stems from the use of an inner loop to search for a matching record in the second array, which basically multiplies the total number of iterations. We can utilize a hash table for faster lookup. The Group-Object cmdlet offers a convenient AsHashTable parameter that can be used here.

Please be warned that the value portion of each entry is an array of matching records. If we are grouping records by using a property with unique values (such as SamAccountName), those arrays will apparently contains one single element each.

So an enhanced version of the code snippet is like this (with the constructing source arrays removed):

$h = $EXList | Group-Object -Property Name -AsHashTable

$ADList | %{

if($h[$_.Name]) {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN; MailServer=$h[$_.Name][0].MailServer}

} else {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN}

}

The last (but not the least) idea is to sort both arrays based on the key property (user name) beforehand, then we can pair records in a single iteration. Note that in this particular example, users found in Active Directory is a superset of users in Exchange, so we need a pointer variable to deal with this little quirk.

$ADList = @"

chwu,chwu@microsoft.com,Chris Wu

tst1,,Test User1

tst2,tst2@contoso.com,Test User2

"@ | ConvertFrom-Csv -Header Name,mail,CN | Sort-Object -Property Name

$EXList = @"

chwu,ex1.contoso.com

tst2,ex2.contoso.com

"@ | ConvertFrom-Csv -Header Name,MailServer | Sort-Object -Property Name

$ADList | % {$p = 0} {

if($_.Name -eq $EXList[$p].Name) {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN; MailServer=$EXList[$p].MailServer}

$p++

} else {

New-Object PSObject -Property @{Name=$_.Name; mail=$_.mail; CN=$_.CN}

}

The last two snippets perform much better than the original one, but which one is faster remains a question (I haven’t tested them against large arrays just yet). I would like to hear about your results, and I welcome your thoughts and ideas.

~Chris

Thanks Chris excellent blog post. Join me tomorrow for more cool Windows PowerShell stuff.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Use PowerShell to Clean Out Temp Folders

Anonymous — Sun, 14 Apr 2013 05:00:00 GMT

Summary: Guest blogger, Bob Stevens, talks about using Windows PowerShell to clean out temporary folders on desktops following a malware infection.

Microsoft Scripting Guy, Ed Wilson, is here. Today, we welcome back our newest guest blogger, Bob Stevens. Yesterday Bob wrote about a quick script that he developed to pick out comments from a Windows PowerShell script: Weekend Scripter: Pick Comments from a PowerShell Script.

I made Bob’s virtual acquaintance recently when I did a Live Meeting presentation to the Twin Cities PowerShell User Group.

Here is Bob’s contact information:

Blog: Help! I’m Stuck In My Powershell!
Twitter: @B_stevens6
LinkedIn: Robert Stevens

Take it away, Bob…

For a local service desk systems analyst, nothing is more frustrating than malware. Not only is it a time sink—it also has the indented potential to cause irreparable damage. No network that connects to the Internet is immune to it.

Most organizations have their own standard operating procedures regarding malware removal. Even so, individuals technician have their special tweaks and tricks to increase the likelihood of success. I like to target the malware where it resides: Temp Folders. And after cleaning and clearing a number of workstations, it occurred to me that I could use a Windows PowerShell script to do just that, saving myself five minutes of hoping that the computer will let me open a folder.

I started by creating a list of the locations that temporary files are automatically placed by the Windows XP operating system (starting with Windows Vista, they are in the C:\Users folder):

C:\Windows\Temp
C:\Windows\Prefetch
C:\Documents and Settings\*\Local Settings\Temp
C:\Users\*\Appdata\Local\Temp

Now that I have defined our locations, I need to define what I want to do. For this, I create a flowchart:

I start with the Set-Location command and define the location as “C:\Windows\Temp”:

Set-Location “C:\Windows\Temp”

Now that I am located in the Windows temp folder, I need to delete the files. This can be done with the old DOS command Del, but I prefer using the Windows Powershell cmdlet Remove-Item to standardize the script. The items need to be removed indiscriminately, so I use a wildcard character. A wildcard character is a special character that represents one or more other characters. The question mark (?) wildcard stands for one character and the asterisk (*) wildcard stands for any number of characters. Because I do not want to discriminate between different files, I use the asterisk.

Remove-Item *

Next I tell the Remove-Item cmdlet to also remove all files in subdirectories with the -recurse switch:

Remove-Item * -recurse

And I tell it to select hidden files with the -force switch:

Remove-Item * -recurse -force

Together the two lines looked like this:

Set-Location “C:\Windows\Temp”
Remove-Item * -recurse -force

I do the same for the rest of the folders and the complete script begins to take shape:

Set-Location “C:\Windows\Temp”
Remove-Item * -recurse -force

Set-Location “C:\Windows\Prefetch”
Remove-Item * -recurse -force

Set-Location “C:\Documents and Settings”
Remove-Item “.\*\Local Settings\temp\*” -recurse -force

Set-Location “C:\Users”
Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

Wait. Why is there an asterisk in the middle of the last path? You can use wildcard characters to do this:

Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

This says, “Look in all folders in this directory with the path structure that matches this.” In my case, this is all of the user profile Local Settings\temp folders.

But this looks very busy, so at Ed Wilson’s suggestion, an array would prevent all the unnecessary jumping around with the Set-Location command. So we change our flowchart to look something like this:

Arrays are a nifty programming feature that groups a number of strings together into one variable, while remaining individual strings. They are defined much like a normal variable—they start with the variable ($) indicator followed by the array name:

$tempfolders

Just like a variable, I use the equal sign (=) to define it.

$tempfolders =

Here is where the arrays and variables differ when defining. I start with the array indicator (@):

$tempfolders = @

And I follow it with parentheses to group strings together:

$tempfolders = @()

What you put inside the parentheses is your choice. For my purposes, I fill it with temp folder paths:

$tempfolders = @( "C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Documents and Settings\*\Local Settings\temp\*", "C:\Users\*\Appdata\Local\Temp\*" )

Notice that each string is neatly encapsulated by double quotation marks (“ ”) and separated by a comma and a space (, ). The quotation marks are necessary for any string with a space in it, and the comma with a space separates the values. Both are essential to define an array. Additionally you can see that each string ends with a wildcard character. This is going to remove the necessity for me to define exactly what to remove in the next line.

Now I use the Remove-Item cmdlet again; but this time for the -path operator, I use the $tempfolders array variable:

Remove-Item $tempfolders -force -recurse

This line instructs Windows Powershell to do exactly the same as previously, but for every item in the array.

Side-by-side, here are the two versions of the script:

1 Set-Location “C:\Windows\Temp”

2 Remove-Item * -recurse -force

3 Set-Location

4 “C:\Windows\Prefetch”

5 Remove-Item * -recurse -force

6 Set-Location “C:\Documents and Settings”

7 Remove-Item “.\*\Local

8 Settings\temp\*” -recurse -force

9 Set-Location “C:\Users”

10 Remove-Item “.\*\Appdata\Local\Temp\*” -recurse -force

1 $tempfolders = @("C:\Windows\Temp\*", "C:\Windows\Prefetch\*", "C:\Documents and Settings\*\Local Settings\temp\*", "C:\Users\*\Appdata\Local\Temp\*")

2 Remove-Item $tempfolders -force -recurse

With two lines of code, I was able to save myself between three minutes and 30 minutes of work. This is the purpose of scripting at its finest: automate repetitive tasks to allow the technician to do more in-depth work. Thank you all for reading, and as always, let me know if you have developed a better way!

~Bob

Bob, thanks again for a real world example and a great suggestion. Join us tomorrow for a blog post by Boe Prox about installing WSUS on Windows Server 2012. It is a great blog and I am sure you will enjoy it.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Pick Comments from a PowerShell Script

Anonymous — Sat, 13 Apr 2013 05:00:00 GMT

Summary: Guest blogger, Bob Stevens, shares a script to pick out comments from a Windows PowerShell script.

Microsoft Scripting Guy, Ed Wilson, is here. Today we have a new guest blogger, Bob Stevens. I made Bob’s virtual acquaintance recently when I did a Live Meeting presentation to the Twin Cities PowerShell User Group.

Here is Bob’s contact information:

Blog: Help! I’m Stuck in My Powershell!
Twitter: @B_stevens6
LinkedIn: Robert Stevens

The floor is yours, Bob…

As a local Help Desk technician, I run into many repetitive support tasks. From low toners to Internet Explorer issues, I have done it all. About three months ago I discovered that I could use PowerShell to automate a number of these tasks, thereby freeing my time for some of the more unusual issues. Fortunately, all of the computers at my site have Windows PowerShell 2.0 installed, so it was a matter of ensuring that they can run scripts. This can be done by changing the Set-ExecutionPolicy cmdlet to Unrestricted in the following manner:

Set-ExecutionPolicy Unrestricted

When the work is done, switch it back to the organization default with:

Set-ExecutionPolicy Remote-Signed

Set-ExecutionPolicy governs which scripts can be run on any given system. By setting it as Unrestricted, I am removing all restrictions. I switch it back to Remote-Signed to prevent users from running scripts that can potentially damage a system, thereby presenting a potential for data loss.

Fast forward three months and multiple scripts later…

It dawned on me that I would need to create documentation for each of these scripts. Documentation provides my coworkers with the insight they need to understand the purpose and functionality of my work and to pick up where I left off should the script need to be altered. Thankfully, like a good Windows PowerShell scripter, I commented liberally throughout my scripts to ensure that I knew where I would need to alter it in the future. To this end I started working on a script to pull comments. I knew that I habitually use single line comments for documentation and block comments for commenting out blocks of code. Happy accident because the script I devised only pulls the first and the last lines of a block comment.

Note For simplicity, I name all directories a variation of “foo” and all input files a variation of “foo.*”. You can set foo as whatever you want.

As usual I started with setting my location:

Set-Location “C:\foo”

Next we set our source script file as a variable. I use variables in my scripts to enable me to change one line of code, rather than five lines, thereby reducing the chance of an error. Variables are defined by the dollar sign ($).

$script = “foo.ps1”

We need to define an output variable as $out. Note that I used the $script variable in the variable value. This will result in the file name of foo.ps1 comments.txt. This is to differentiate between output files. For this to work, there must be a space between $script and comments.txt:

$out = “$script comments.txt”

Now that we have defined the output file name, we need to create the output file itself, and I do this with the New-Item cmdlet. Of course, we need to define the object as a file—otherwise we get a dialog box asking us if it’s a file or folder:

New-Item “out” -ItemType File

Now our preparation is complete:

Set-Location "c:\foo"

$script = "foo.ps1"

$out = "$script comments.txt"

New-Item "$out" -ItemType File

We need to pull the content of our source file with the Get-Content cmdlet:

Get-Content $script

The next line is to prevent Windows PowerShell from appending the output to output that already exists in the variable by creating an array, this is done with the array (@) operator, followed by both parentheses:

$comments = @()

This is where the magic takes place. We need to use the Select-String cmdlet. This command requires two parameters: Pattern and File. Both values need to be quoted if you are not using a variable to define it. As we are searching for comments, we are going to select strings that contain “#”:

Select-String -Pattern “#” $script

This is a bit more complex, and it requires stringing three commands together, so we use the pipe (|) operator. The pipe operator merely states do “this” and then do “that” with the output of “this.” Pipe operators must always have a space preceding and succeeding it:

Select-String -Pattern “#” $script |

For our purposes, we are going to say, “For each object, do this.” Coincidentally (or not), Microsoft decided to add a Foreach-Object cmdlet for just this purpose! And everything that you are doing with Foreach-Object must be in braces to group them together:

Select-String - Pattern “#” $script |

Foreach-Object {}

When we string commands like this together, formatting is important—not for functionality, but for readability. Now we need to comment the full line where “#” appears. It is important to note that you must use “+=”, or you will end up with an empty file:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

}

We need to tell Windows PowerShell to grab everything after “#” in that string. This is tricky, but it can be done with the context.postcontext definition:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

We now need to tell Windows PowerShell to extract everything that we just defined within the Foreach-Object curly brackets:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments

Finally, we dump our output into the output file $out with the Set-Content cmdlet:

Select-String - Pattern “#” $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments | Set-Content $out

The complete script looks something like this:

Set-Location "c:\foo"

$script = "foo.ps1"

$out = "$script comments.txt"

New-Item "$out" -ItemType File

Get-Content $script

$comments = @()

Select-String -Pattern "#" $script |

Foreach-Object {

$comments += $_.line

$comments += $_.context.postcontext

}

$comments | Set-Content $out

The result should take the following input:

And give you the following output (Select-String -pattern “#” shows up because it contains a “#”):

This saved me an hour now and countless future hours that I would spend extracting comments for documentation.

When I was verifying my work, I ran across the following note to myself stating that I referenced a Rob Campbell in another script. Some of the code made it in here.

Rob Campbell, Mjolinor: How do you extract data from a txt file with powershell. As always, input is always appreciated.

Thank you for your time. I uploaded the complete script to the Script Center Repository: Extracting Comments from a Script with PowerShell.

~Bob

Thank you, Bob, for sharing your script and your insight with us today. Join us tomorrow when Bob talks about a script he wrote to clean up user profiles. It is cool, and you do not want to miss it.

Ed Wilson, Microsoft Scripting Guy

Do One Thing and Do It Well

Anonymous — Sun, 07 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVPs, Don Jones and Jeffery Hicks, talk about a fundamental tool design consideration.

Microsoft Scripting Guy, Ed Wilson, is here. This week we will not have our usual PowerTip. Instead we have excerpts from seven books from Manning Press. In addition, each blog will have a special code for 50% off the book being excerpted that day. Remember that the code is valid only for the day the excerpt is posted. The coupon code is also valid for a second book from the Manning collection.

This excerpt is from Learn PowerShell Toolmaking in a Month of Lunches
By Don Jones and Jeffery Hicks

Here’s a basic tenant of good Windows PowerShell tool design: do one thing, and do it well. Broadly speaking, a function should do one—and only one—of these things:

Retrieve data from someplace
Process data
Output data to some place
Put data into some visual format meant for human consumption

This fits well with the command-naming convention in Windows PowerShell: If your function uses the verb Get, that’s what it should do: get. If it’s outputting data, you name it with a verb like Export, or Out, or something else. If each command (okay, function) worries about just one of those things, then they’ll have the maximum possible flexibility.

For example, let’s say we want to write a tool that will retrieve some key operating system information from multiple computers and then display that information in a nicely formatted onscreen table. It’d be easy to write that tool so that it opened Active Directory, got a bunch of computer names, queried the information from them, and then formatted a nice table as output.

The problem?

Well, what if tomorrow we didn’t want the data on the screen but rather wanted it in a CSV file? What if one time we needed to query a small list of computers rather than a bunch of computers from the directory? Either change would involve coding changes, probably resulting in many different versions of our tool lying around. Had we made it more modular and followed the basic philosophy we just outlined, we wouldn’t have to do that. Instead, we might have designed the following:

One function that gets computer names from the directory
One function that accepts computer names, queries those computers, and produces the desired data
One function that formats data into a nice onscreen table

Suddenly, everything becomes more flexible. That middle function could now work with any source of computer names: the directory, a text file, or whatever. Its data could be sent to any other command to produce output. Maybe we’d pipe it to Export-CSV to make that CSV file or to ConvertTo-HTML to make an HTML page. What about the onscreen table we want right now? We’re betting Format-Table could do the job, meaning we don’t even have to write that third function at all—less work for us!

So let’s talk about function design. We’re going to suggest that there are really three categories of functions (or tools): input, functional, and output.

Input tools

Input tools are the functions that don’t produce anything inherently useful, but are rather meant to feed information to a second tool. So a function that retrieves computer names from a configuration management database is an input tool. You don’t necessarily want the computer names, but there might be an endless variety of other tools that you want to send computer names to—including any number of built-in Windows PowerShell commands.

Here’s a good example of how to draw a line between your functions. Let’s say you’re writing a hunk of commands intended to retrieve computer names from your configuration management database. Your intent today is to query some WMI information from those computers—but aren’t there other tools that need computer names as input? Sure! Restart-Computer accepts computer names. So does Get-EventLog, Get-Process, Invoke-Command, and a dozen more commands. That’s what suggests (to us, at least) that functionality for getting names from the database should be a standalone tool. It could potentially feed a lot more than only today’s current needs.

Windows PowerShell already comes with a number of input tools. Sticking with the theme of getting computer names, you might use Import-CSV, Get-Content, or Get-ADComputer to retrieve computer names from various sources. To us, this further emphasizes the fact that the task of getting computer names is a standalone capability, rather than being part of another tool.

Functional tools

This is the kind of tool you’ll be writing most often. The idea is that this kind of tool doesn’t spend time retrieving information that it needs to do its main job. Instead, it accepts that information via a parameter of some kind—that parameter being fed by manually entered data, by another command, and so on.

So if your functional tool is going to query information from remote computers, it doesn’t internally do anything to get those computers’ names; but instead, it accepts them on a parameter. It doesn’t care where the computer names come from—that’s another job.

When it’s been given the information it needs to operate, a functional tool does its job and then outputs objects to the pipeline. Specifically, it outputs a single kind of object, so that all of its output is consistent. This functional tool also doesn’t worry about what you plan to do with that output—it simply puts objects into the pipeline. This kind of tool doesn’t spend a nanosecond worrying about formatting, about output files, or about anything else. It does its job, perhaps produces some objects as output, and that’s it.

Note Not all functional tools will produce output of any kind. A command that just does something—perhaps reconfiguring a computer—might not produce any output, apart from error messages if something goes wrong. That’s fine.

Output tools

Output tools are specifically designed to take data (in the form of objects), which has been produced by a functional tool, and then put that data into a final form. Let’s stress that: final form. We looked up final in our dictionary, and it says something like, “pertaining to or coming at the end; last in place, order, or time.” In other words, when you send your data to an output tool, you’re finished with it. You don’t want anything else happening to the data. You want to save it in a file or a database, or display it onscreen, or fax it to someone, or tap it out in Morse code…whatever. Windows PowerShell verbs for this include Export, Out, and ConvertTo, to name a few.

Consider the inverse of this philosophy: If you have a tool that’s putting data into some final form, like a text file or an onscreen display, that tool should be doing nothing else. Why?

Consider a function that we’ve created, named Get-ComputerDetails. This function gets a bunch of information from a bunch of computers. It then produces a pretty, formatted table on the screen. That’s a text-based display. Doing so means we could never do this:

Get-ComputerDetails | Where OSBuildNumber –le 7600 |

Sort ComputerName | ConvertTo-HTML | Out-File computers.html

Why couldn’t we do that? Because, in this example, Get-ComputerDetails is producing text. Where-Object, Sort-Object, and ConvertTo-HTML can’t deal with text—they deal with objects. Get-ComputerDetails has put our data into its final form, meaning—according to the dictionary—that Get-ComputerDetails is “coming at the end” and should be “last in place.” Nothing can come after it—meaning we have less flexibility.

A better design would have had Get-ComputerDetails produce only objects and to create a second command, perhaps called Format-MyPrettyDisplay, which handles the formatting. That way we could get our originally desired output:

Get-ComputerDetails | Format-MyPrettyDisplay

But we could also do this:

Get-ComputerDetails | Where OSBuildNumber –le 7600 |

Sort ComputerName | ConvertTo-HTML | Out-File computers.html

This would allow us to change our minds about using Format-MyPrettyDisplay from time-to-time, instead sending our data objects on to other commands to produce different displays, filter the data, source the data, create files, and so on.

This blog discussed the basics of good Windows PowerShell tool design. A function should perform only one of the following actions:

Retrieve data from someplace
Process data
Output data to some place
Put data into a visual format meant for human consumption

We talked about three different categories of functions, or tools: input, functional, and output.

~Don and Jeffrey

Here is the code for the discount offer today at www.manning.com: scriptw7
Valid for 50% off Learn PowerShell Toolmaking in a Month of Lunches and SharePoint 2010 Owner's Manual
Offer valid from April 7, 2013 12:01 AM until April 8, midnight (EST)

Ed Wilson, Microsoft Scripting Guy

Performance Counters and Windows System Assessment Report

Anonymous — Sat, 06 Apr 2013 05:00:00 GMT

Summary: Microsoft PowerShell MVP, Richard Siddaway, talks about using Windows PowerShell and WMI to work with performance counters and Windows assessment.

This excerpt is from PowerShell and WMI
By Richard Siddaway

Measuring system performance has traditionally involved looking at the performance counters. These can be accessed through the performance monitor (SYSMON for those who remember earlier versions of Windows), and they can be saved as required. You can also use the Get-Counter cmdlet (which works against remote machines), or you can use the WMI Win32_Perf* classes.

Windows Vista introduced the system assessment report. This rates a number of system hardware components (including memory, CPU, disk, and graphics) to produce an overall rating for the system. The higher the score, the better the system should perform.

I’m often asked about system stability. The number of unscheduled restarts is one way to measure stability. Later versions of Windows calculate a stability index on an hourly basis. This is calculated based on failures and changes, with recent events being more heavily weighted. The maximum possible score is 10.

Performance counters are still required to dig into individual aspects of the system. In this set of tips, we’ll cover performance counters and Windows system assessment reports.

Reading performance counters

If you’ve spent any time investigating system performance, you know that there’s a huge list of available Windows performance counters. The problem of finding the correct counter to use is increased when you consider that applications such as SQL Server, IIS, and Exchange Server add their own raft of counters. WMI enables you to access some, but not all, of the counters.

You can see which counters are available on a specific system like this:

Get-WmiObject -List Win32_PerfFormattedData* | select name

Here’s an extract from the results:

Win32_PerfFormattedData_PerfDisk_LogicalDisk

Win32_PerfFormattedData_PerfDisk_PhysicalDisk

Win32_PerfFormattedData_PerfOS_PagingFile

Win32_PerfFormattedData_PerfOS_Processor

Win32_PerfFormattedData_PerfOS_Memory

You should use the Recurse parameter when searching for these classes because they won’t necessarily be added to the default WMI namespace.

Tip The Win32_PerfFormattedData class is a superclass that will call the other performance formatted data classes. There will be a lot of data to wade through.

There are also related classes that return the raw performance counter data. These classes are difficult to use, because each value has to be processed through a calculation to derive a meaningful result. It’s easier to use the formatted WMI classes or Get-Counter.

Problem

You need to monitor the processor performance of one of your systems. The server has multiple processors (or cores), and you need to display the information for each processor core and the total to ensure that the application is using the processor resources in an optimum manner.

Solution

The following listing presents a function that takes a computer name and a number as parameters. The number determines how many times you’ll sample the processor information.

Listing 1 Accessing performance counters

function get-cpucounter{

[CmdletBinding()]

param (

[parameter(ValueFromPipeline=$true,

ValueFromPipelineByPropertyName=$true)]

[string]$computername="$env:COMPUTERNAME",

[int]$number=1

)

BEGIN{ #1

$source=@"

public class CPUcounter

{

public string Timestamp {get; set;}

public string Name {get; set;}

public ulong PercProcTime {get; set;}

}

Add-Type -TypeDefinition $source -Language CSharpversion3

}#begin

PROCESS{

1..$number | foreach {

$date = (Get-Date).ToString()

Get-WmiObject -Class Win32_PerfFormattedData_PerfOS_Processor `

-ComputerName $computername | foreach {

$value = New-Object -TypeName CPUCounter -Property @{

TimeStamp = $date

Name = $_.Name #2

PercProcTime = $_.PercentProcessorTime

}

$value

}

Start-Sleep -Seconds 1 #3

}

}#process

}

#1 Create class

#2 Create object and set properties

#3 Pause execution

Some inline C# code is used to create a new .NET class to store your results (#1). The class defines three properties—a timestamp, the name of the processor, and the percentage processor time (how much it was used during the measurement period). This is compiled by using Add-Type. Creating a class in this manner enables you to strongly type the properties, which supplies another level of error checking.

The range operator (..) is used to put the required series of numbers into the pipeline. Windows PowerShell will process each value, and for each of them retrieve the processor performance data by using Win32_PerfFormattedData_PerfOS_Processor. One object per processor, plus one for the total, will be returned. You create an object by using your specially created .NET class, populate its properties (#2), and output it. A one-second pause is activated before you start again (#3).

On my development system, I use this code:

1..10 | foreach {Measure-Command -Expression {Get-WmiObject

[CA] -Class Win32_PerfFormattedData_PerfOS_Processor }}

It show that the Get-WmiObject command takes about 300 milliseconds to retrieve the data. The function could be altered to change the delay, or you could even make it a parameter.

Discussion

The following image displays the results from using this function. The results show that processing is relatively equally distributed across the two cores. I wouldn’t expect to see the values being identical across all processors or cores all of the time.

Tip In case you’re wondering how I managed to drive processor performance so high, I set a few continuously looping recursive directory listings. They’re a good way to tax the system without spending a lot of money on simulation tools.

Each of the WMI performance counter classes will need to be investigated to determine the properties that you need to record. For example, the class used here also returns information regarding interrupts.

One common scenario that you’ll get is users’ claiming a difference in performance between two systems. You can use the Windows system assessment report to provide a high-level comparison between the hardware of the two systems.

Windows system assessment report

The assessment report was introduced in Windows Vista. It examines a number of hardware components to determine an overall score for the system.

Tip The overall score is determined by the lowest of the individual component scores. Always examine the full report to determine whether a single component is adversely affecting performance.

Accessing this information for the local computer through the GUI is acceptable, but you also need a way to perform this action remotely.

Problem

You need to create Windows system assessment reports for a number of remote computers. This will enable you to determine which computers should be refreshed and which are worth reusing.

Solution

The following listing utilizes the Win32_WinSat class to solve this issue. A hash table lookup is created to decode the assessment state property.

Listing 2: System assessment information

$satstate = DATA {

ConvertFrom-StringData -StringData @'

0 = StateUnknown

1 = Valid

2 = IncoherentWithHardware

3 = NoAssessmentAvailable

4 = Invalid

}

function get-systemassessment{

[CmdletBinding()]

param (

[parameter(ValueFromPipeline=$true,

ValueFromPipelineByPropertyName=$true )]

[string]$computername="$env:COMPUTERNAME"

)

PROCESS{

Get-WmiObject -Class Win32_WinSat -ComputerName $computername |

select CPUScore, D3DScore, DiskScore, GraphicsScore,

MemoryScore, TimeTaken,

@{N="AssessmentState"; E={$satstate["$($_.WinSATAssessmentState)"]}},

@{N="BaseScore"; E={$_.WinSPRLevel}}

}#process

}

The function returns the data from the WMI class and uses Select-Object to output the properties and two calculated fields. One calculated field decodes the assessment state and the other renames the overall score.

Discussion

This report shouldn’t be taken in isolation when looking at system performance. The age of the system and any remaining warranty should also be considered.

Working with event logs, scheduled jobs, and performance indicators is an essential part of the administrator’s role. Windows PowerShell and WMI provide a number of tools to help you in these tasks:

Event log discovery and configuration
Backup and clearing of event logs
Lifecycle management for scheduled jobs, including creation, discovery, and deletion
Retrieval of data from performance counters
Production of system assessment reports and stability index data

These techniques enable you to gather data for possible forensic investigations, perform out-of-hours tasks through scheduling jobs, and determine how your systems are performing in real time and with a historic perspective. We discussed two of those techniques: performance counters and Windows system assessment reports.

~Richard

Here is the code for the discount offer today at www.manning.com: scriptw6
Valid for 50% off PowerShell and WMI and SharePoint 2010 Workflows in Action
Offer valid from April 6, 2013 12:01 AM until April 7, midnight (EST)

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Managing Dell AppAssure with Windows PowerShell

Anonymous — Sun, 31 Mar 2013 05:00:00 GMT

Summary: Guest blogger, Mike Robbins, talks about using Windows PowerShell to manage Dell AppAssure.

Microsoft Scripting Guy, Ed Wilson, is here. Guest blogger, Mike Robbins, returns today to share his experience. You can also read previous blogs by Mike.

Mike Robbins is a senior systems engineer with almost 20 years of professional experience as an IT pro who currently works for a healthcare company located in Meridian, MS. During his career, Mike has provided enterprise computing solutions for educational, financial, healthcare, and manufacturing customers. He’s a Windows PowerShell enthusiast who uses Windows PowerShell on a daily basis to administer Windows Server, Hyper-V, SQL Server, Exchange Server, SharePoint, Active Directory, Terminal Services, EqualLogic Storage Area Networks, AppAssure, and Backup Exec. Mike is an author of a chapter in the book PowerShell Deep Dives, he has presented sessions at PowerShell Saturday 003 in Atlanta, for the Mississippi PowerShell User Group, and for the Florida PowerShell User Group. Mike is also one of the cofounders of the Mississippi PowerShell User Group.

Blog: Mike F Robbins Computing Solutions
Twitter: @mikefrobbins
Mississippi PowerShell User Group

Here’s Mike…

For those of you not familiar with Dell AppAssure, it’s a backup, replication, and recovery solution. More information about this product can be found on the AppAssure website.

It’s no secret that I’m a big fan of Windows PowerShell so when a third-party vendor, such as Dell, adds PowerShell support to their products, I also become very interested in those products. (I’m not affiliated with Microsoft, Dell, or AppAssure in any way other than being a customer.)

AppAssure added Windows PowerShell support via a Windows PowerShell module in version 5.3.1 of their product. This module named AppAssurePowerShellModule includes a total of 31 cmdlets, which are listed in the following image:

Usually most vendors are slow to support the latest and greatest version of Windows PowerShell, but not AppAssure. According to AppAssure’s support documentation, How to Import the AppAssure 5 PowerShell Module, they prefer Windows PowerShell 3.0, although Windows PowerShell 2.0 is also supported. The examples found in this blog use Windows PowerShell 3.0 syntax, which also means that the AppAssure PowerShell module doesn’t have to be explicitly imported before using the cmdlets. If you were running Windows PowerShell 2.0, you would need to import the AppAssure PowerShell module by using the following command prior to attempting to use any of the cmdlets:

In the previous example, Name is a positional parameter which can be omitted if the first item specified after Import-Module is the name of the Windows PowerShell module.

From what I’ve seen in the industry, the average IT pro isn’t using Windows PowerShell yet. Hopefully that will soon change with more third-party vendors adding Windows PowerShell integration to their products and with cmdlets (such as those in the AppAssure PowerShell module) being so easy to use. Most of the cmdlets in the AppAssure PowerShell module require only opening Windows PowerShell on the AppAssure core server and running the cmdlet with no parameters or with very few mandatory parameters being required.

The Get-ProtectedServers cmdlet is a perfect example of this. It returns all of the servers that are protected by the AppAssure core server that you’re currently logged in to without specifying anything other than the cmdlet name. The information provided includes the server names, status, AppAssure agent version, and a few other properties:

Wasn’t that much easier and more efficient than using the GUI to retrieve this information? Grouping the protected servers to determine how many are listed for each version, or returning a list that is grouped by version (including the names of the protected servers for each version) are also easy tasks when using Windows PowerShell:

I’ve found something that it is difficult to determine in the AppAssure GUI. When I start replicating protected servers to another AppAssure core server, and I choose to initially seed the transfer via SneakerNet, how do I know when the seeding of the protected server to the portable media device is complete?

This is something that’s very important. Disconnecting it from the source AppAssure core server and shipping it to the site where the destination AppAssure core server resides, before the seeding process has completed, could cause the protected servers to not be replicated, not have a replicated base image, or have an orphaned chain of recovery points. Determining the seed drive progress for each protected server that you’ve chosen to replicate to a remote AppAssure core server is also easy to determine with Windows PowerShell as shown in the following example:

I’m not really a big fan of logging on to a server via a remote desktop to manage it. In the following scenario, I use the New-PSSession cmdlet to create a persistent connection to three AppAssure core servers. Two of the servers are in different Active Directory forests than the Windows 8 workstation where I am running the commands. Each of these AppAssure core servers requires different credentials than those I’m currently using on my workstation and to run Windows PowerShell. They also each require different credentials than the others:

According to the previously referenced AppAssure article, How to Import the AppAssure 5 PowerShell Module, the module shouldn’t be imported on a non-AppAssure core server. This is why I don’t have the AppAssure Windows PowerShell module installed on my local workstation. Using the Windows PowerShell Invoke-Command cmdlet allows us to remotely manage multiple AppAssure core servers while staying within the recommended supported configuration for using their Windows PowerShell module.

Now I can use a single Windows PowerShell command to check the status of all the protected servers in the three datacenters, which have an AppAssure core server. I want to know if any of the servers that are supposed to be protected by AppAssure aren’t being protected:

Based on the results in the previous example, I have one server out of all the protected servers in all three datacenters that has a status of unreachable. This doesn’t seem too impressive until you factor in that the three datacenters have a total of 53 protected servers:

With that many servers, it’s easy to see how efficient it is to use this Windows PowerShell command rather than using the AppAssure GUI (web) interface. It took a total of 1 minute and 25 seconds to query the three AppAssure core servers for the status on all 53 protected servers:

Two of the AppAssure core servers and twenty-two of the protected servers in the previous example reside at remote datacenters that are connected via a VPN across the Internet (not on the LAN).

We’ve only looked at one of the cmdlets provided in the AppAssure PowerShell module in this blog, but there’s much more that can be done with Windows PowerShell when it comes to managing AppAssure. Want to protect a new server? That’s what the Start-Protect cmdlet is for. Want to pause the AppAssure replication between AppAssure core servers during business hours and resume it after business hours due to bandwidth constraints?

That’s what the Suspend-Replication and Resume-Replication cmdlets are for. This is also where Windows PowerShell 3.0 comes in handy. You could use Windows PowerShell to set up scheduled tasks that run Windows PowerShell commands to pause and resume the replication. I wrote a blog about that very subject last month: Use PowerShell to Create a Scheduled Task that Uses PowerShell to Pause and Resume AppAssure Core Replication. It demonstrates this process, if it’s something of interest.

There is also an AppAssure event log added to the AppAssure core server during installation of the product that contains an abundance of information that can be queried by using Windows PowerShell—as you would any other event log.

Where can we find more information about Managing Dell AppAssure with Windows PowerShell? In the AppAssure 5 Technical Documentation section of the AppAssure website, there’s an AppAssure 5 PowerShell Reference Guide. You could also view the Help for the cmdlets contained in the AppAssure PowerShell module. If you’re interested in more blog posts about using Windows PowerShell to manage Dell AppAssure, see the AppAssure category on my site, Mike F Robbins Computing Solutions.

I would also like to invite you to join us on the second Tuesday of each month at 8:30 PM Central Time for the Mississippi PowerShell User Group meetings. These meetings are held online (virtual) via Microsoft Lync. Anyone from anywhere can join in and learn more about Windows PowerShell from our awesome line-up of speakers that we have scheduled throughout 2013. Each of our guest speakers for the remainder of this year is an author of at least one chapter in the book PowerShell Deep Dives.

~Mike

Awesome blog post, Mike. Thank you so much for taking the time to share your experience with us.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Run C# Code from Within PowerShell

Anonymous — Sat, 30 Mar 2013 05:00:00 GMT

Summary: Learn how to execute C# programs from source without a compiled binary by using Windows PowerShell.

Microsoft Scripting Guy, Ed Wilson, is here. Today guest blogger, Ingo Karstein, is back with us to share his knowledge. You can also read previous guest blogs by Ingo. Take it away Ingo…

Some time ago, I created a script called PS2EXE that creates EXE files out of Windows PowerShell script files. It is posted on the Hey, Scripting Guy! Blog: Learn About Two CodePlex Projects: PS2EXE and RoboPowerCopy.

Now I have created another script, rather the opposite of PS2EXE: C#Script. This script is able to execute C# programs from source code without a compiled binary.

I’ve done this because I have several C# tools that I always use for my daily business. Some of them are not easily convertible to Windows PowerShell. But I like the fact that script files are always readable because you only need the source code, no compiler. There is no need for binaries with separate source projects somewhere on the hard disk, so I decided to create a script with the purpose of running C# code inside Windows PowerShell.

The idea is simple:

Take a C# program file and compile it into the memory.
Search for the Main method and call them using .NET reflection.
Add some basic .NET console support to write output from the C# program to the Windows PowerShell environment.

The C# program will be executed in a real .NET thread that is created in the Windows PowerShell script by using a helper class that is compiled in memory at runtime too. This helper class provides some synchronous .NET events that can be subscribed in Windows PowerShell to handle the console output.

Note You can download C#Script from the Microsoft TechNet Gallery: C#Script: Execute source code C# programs from PowerShell. You should be aware of the following limitations:

This project is in the alpha state! There will be errors in it. So please be careful, especially in a production environment.
Console input not implemented. Therefore, we need a custom class derived from System.IO.TextReader.
There is no resource file support! It is just plain C#.

To demonstrate the script, I created two C# demo projects: “Test” and “TestWin.” The first one is a console application, the second is a Windows Forms application.

The following screenshot shows my “TestWin” demo project. My csscript.ps1 file is in the folder “C:\source2\csscript,” and “testwin” is in the subfolder. (The Windows 8 operating system is in German, but you get the point, I’m sure.)

Let’s have a look into “TestWin.” The following screenshot is from the Visual Studio 2012 project.

Of course it can be run in Visual Studio 2012 or as standalone .NET assembly (EXE file). The list box is empty. It would show the program's arguments if there were any.

At the beginning of the Program.cs file, there is an XML configuration section for C#Script:

//<csscript>

// <nodebug/>

// <references>

// <reference>System</reference>

// <reference>System.Core</reference>

// <reference>System.Data</reference>

// <reference>System.Data.DataSetExtensions</reference>

// <reference>System.Xml</reference>

// <reference>System.Xml.Linq</reference>

// <reference>System.Windows.Forms</reference>

// <reference>System.Drawing</reference>

// </references>

// <mode>winexe</mode>

// <files>

// <file>Form1.cs</file>

// <file>Form1.Designer.cs</file>

//// <file>Test</file>

// </files>

//</csscript>

This rules the compilation of the program when using C#Script. Here, you specify the .NET assembly references, the execution mode, and the source files. By using four slash characters, the line will be ignored. In the “files” section, you specify all necessary C# files if there are more than one. The additional files do not need XML configuration.

In my demo, the project needs three C# files to run: Program.cs, Form1.cs, and Form1.Designer.cs. The configuration XML is stored only at the beginning of Program.cs.” By using <debug/>, it’s possible to debug the C# program file. I will show that later.

Now let’s go to the Windows PowerShell command line and use C#Script:

At the command line, I type:

.\csscript.ps1 .\testwin\testwin\Program.cs "Greetings" "from" "germany" "!"

That’s it.

Let’s have a look at the console application demo.

At the Windows PowerShell command line, I type:

.\csscript.ps1 .\test\test\Program.cs "Greetings" "from" "germany" "!"

Here I use the <debug/> configuration to be able to debug the program. This gives me the Debugger Attach dialog from Visual Studio 2012 when I run the previous command-line statement:

You will automatically get the source file of the C#Script internal helper class with hard coded breakpoints:

Here you can see how it works inside: Internally it creates a thread and executes the original program by reflection. The Main method of the C# program is given in Method parameter, and the command-line arguments are in the prms parameter.

The next hard coded breakpoint is specified in the Program.cs file. The file will have a new name. (Here the name is n_dspgoj.0.cs.)

This is the output in the console:

In the C#Script package, I’ve included a file named “csscript.bat” that helps you execute csscript from the traditional Windows shell:

You can use it like this:

I’ve tested this C#Script with one of my favorite tools: the SharePoint Feature Administration and Clean Up Tool (it’s a Windows Forms application).

1. I downloaded the code from CodePlex: SharePoint Feature Administration and Clean Up Tool
2. Unzip to a folder.
3. Create a batch file “run.bat.”

@echo off

call csscript.bat "FeatureAdmin2013-VisualStudio2012\Program.cs"

4. Copy “csscript.ps1” and “csscript.bat” into the folder.

5. Modify the file “Program.cs” to contain the config XML structure.

Note “requiredframework” and “requiredplatform” are set because SharePoint 2013 needs .NET Framework 4.0 and 64-bit processes.

6. Execute the program with “run.bat” without compilation in VS2012.

For this program, I’ll not need a compiled EXE anymore! Now I’d like to get your response! If you found any errors, please report them on the TechNet Gallery page: C#Script: Execute source code C# programs from PowerShell. Please feel free to modify C#Script and send me your changes.

~Ingo

Ingo, thank you for sharing this with us today. I love it.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Convert Word Documents to PDF Files with PowerShell

Anonymous — Sun, 24 Mar 2013 05:00:00 GMT

Summary: Windows PowerShell MVP, Sean Kearney, talks about using Windows PowerShell to convert Word documents to PDF files en-masse.

Microsoft Scripting Guy, Ed Wilson, is here. Today’s blog is brought to you by Windows PowerShell MVP and honorary Scripting Guy, Sean Kearney.

Previous blog posts by Sean Kearney

Take it away Sean…

My boss looks up at me today, and sighs, “I love the built-in SaveAs PDF in Word 2013. But I want to do multiple documents at the same time. Oh, if ONLY there was some way to do this in bulk.”

The wires and lights starting blinking in my head. I’m about to leap out of my chair because I hear “Bulk.” Many to do, repeatable, and…

POWERSHELL!

So accessing a file in Microsoft Word programmatically is quite easy. We’ve been doing it for years.

$Word=NEW-OBJECT –COMOBJECT WORD.APPLICATION

$Doc=$Word.Documents.Open(“C:\Foofile.docx”)

And along the same lines, we could save this same file in the following manner.

$Doc.saveas([ref] “C:\Foofile.docx”)

If we would like to save it in an alternate format, like in .pdf format, things get a wee bit fancier. We have to speak a bit of .NET.

$Doc.saveas([ref] “C:\Foofile.pdf”, [ref] 17)

If your brain didn’t pop out just now, you’re OK. Let’s get a little fancier. What if I want Microsoft Word to save that PDF file with the same name as the parent without knowing the name?

Now we’re stepping into the land of fun. We can access the file name of that single document in the following way. Three of the available properties in the Word object are the Name of the document, the Path to the document, and the FullName path. I poked out using the following cmdlet to…well, to be honest…to guess.

$Doc | get-member –membertype property *Name*

Note the two little nuggets. In poking about and using a similar search for Path, I found the property holding its path.

$Doc | get-member –membertype property *Path*

So I could do something like this: Open some file, get the file name information, swap out .docx with .pdf, and then save it.

With these three bits of information, I don’t have to actually know the file name. Word will tell me based on the document. But let’s simplify this down a bit. Let’s just take a known file name and resave it as a PDF file with the same file name. All we need to do is run a Replace() method on the provided file name, and swap .docx with .pdf.

Yes….we’re presuming it’s a .pdf, J.

$File=”C:\Foofolder\foofile.docx”

$Word=NEW-OBJECT –COMOBJECT WORD.APPLICATION

$Doc=$Word.Documents.Open($File)

$Doc.saveas([ref] (($File).replace(“docx”,”pdf”)), [ref] 17)

$Doc.close()

So that’s all fine and dandy. But what if we have a folder of DOCX files that we want to convert at once?

Let’s pretend we ran the following lines in Windows PowerShell:

$File=”C:\Foofolder\foofile.docx”

$Files=GET-CHLDITEM ‘C:\FooFolder\*.DOCX’

Now we could cheat and access the full file name and path by accessing the FullName from the drive system. But let’s have some fun with Word and ask it these questions.

Foreach ($File in $Files) {

# open a Word document, filename from the directory

$Doc=$Word.Documents.Open($File.fullname)

Now let’s ask Word what is the name of the file. And while we’re at it, let’s swap the .docx file extension with .pdf.

$Name=($Doc.Fullname).replace(“docx”,”pdf”)

Then we’ll access that file within Microsoft Word and use the built-in SaveAs PDF option in Word 2010 or Word 2013 to produce a PDF file in the same folder as the original Word document. When done, we close the file.

$Doc.saveas([ref] $Name, [ref] 17)

$Doc.close()

}

So when done our script will look like this:

# Acquire a list of DOCX files in a folder

$Files=GET-CHLDITEM ‘C:\FooFolder\*.DOCX’

Foreach ($File in $Files) {

# open a Word document, filename from the directory

$Doc=$Word.Documents.Open($File.fullname)

# Swap out DOCX with PDF in the Filename

$Name=($Doc.Fullname).replace(“docx”,”pdf”)

# Save this File as a PDF in Word 2010/2013

$Doc.saveas([ref] $Name, [ref] 17)

$Doc.close()

}

So why the big secrecy about using the document names in Word itself? In the future, I’ll show you how to programmatically trigger a mail merge, and you’ll see where it’s needed there.

Cheers and remember to keep on scriptin’.

~Sean,
The Energized Tech

Thanks, Sean, for taking the time to share your scripting expertise with us today. Join me tomorrow when I have a guest blog post from Ingo Karstein about using Windows PowerShell with SharePoint. It is cool and you do not want to miss it.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: The PowerShell Community State of the Union

Anonymous — Sun, 03 Mar 2013 06:00:00 GMT

Summary: The Scripting Wife provides a status update on the Windows PowerShell Community and insights on upcoming activities.

Microsoft Scripting Guy, Ed Wilson, is here. Today I was busy working on a Windows PowerShell script when the Scripting Wife came floating in and asked me if she could write a guest blog. When that happens (for that matter, whenever the Scripting Wife asks for anything), the answer is always, “Yes, of course.” So without further delay, here is Teresa Wilson, aka The Scripting Wife.

PowerShell User Group update

Hello Scripters. Hope you are having a wonderful day. I asked Ed if I could write today about some new information for user groups and about a couple of upcoming events. Although he is a good husband and he usually agrees with things I ask him to do, he also is a great advocate for Windows PowerShell and the PowerShell community, which meant he said, “Of course.”

In June, I offered some information about starting a Windows PowerShell User Group in my blog, Scripting Wife Discusses Setting Up a PowerShell User Group.

Here is the list of items that I suggested:

Create your user group name and register it at PowerShell Community Groups.
Create a Twitter account for the group.
Sign up at Microsoft User Group Support Services.
Sign up at GITCA.
Sign up at INETA.
Register at O’Reilly User Groups.
Find a location to host the meetings.
Identify and contact sponsors.

And now the new kids in town...

And finally, one change that I am aware of:

This is now Microsoft Tech Affiliate Program.

I will continue to update you as I know new or different ideas to help get your group rolling.

If you go to the Scripting Community tab on the Script Center, there is a list of Ed’s upcoming engagements. Typically if Ed is there, I will be also. I cannot answer your questions about how to troubleshoot your script, but I know where to find answers. I am also happy to talk with people and remember what city they live near, then connect people as time goes by. So be sure to stop by and say, “Hello!” if you attend any of the events that Ed and I are attending.

Two big events coming up are the PowerShell Summit North America 2013 in Redmond, Washington in April and TechEd North America 2013 in New Orleans in June. I will be at the Scripting Guy booth the majority of the time. I typically only sneak off to grab a drink or a bite to eat. I love being at the booth and talking to people as they come through.

As always, contact me on twitter @ScriptingWife or email me at ScriptingWife@hotmail.com if I can be of assistance. Have a scriptastic day.

Thanks for a great blog post, Teresa, and for sharing your user group experience with the community.

Ed Wilson, Microsoft Scripting Guy