I created a small library of functions for creating word documents using PowerShell. The library contains 8 functions that allow you to create simple documents in Word2007 (maybe also Word 2003 but I haven’t been able to test it yet).

The functions are:

1. WORD\Invoke-Word
2. WORD\Add-Heading
3. WORD\Add-Paragraph
4. WORD\Add-Table
5. WORD\Add-TableOfContents
6. WORD\Add-PageBreak
7. WORD\Add-TextBox
8. WORD\Update-TablesOfContents

A small example script is included in the zip file which can be downloaded here.

A screenshot of one of the chapter generated by the example script:

A while ago my colleague Martin Zugec posted about a Gotcha concerning return values from subroutines. Read the full story here:

http://martinzugec.blogspot.com/2008/08/returning-values-from-fuctions-in.html

In our scripting framework basically every server takes care of it own configuration. This is also the case when managing Citrix policies. The policies themselves are imported and exported for DTAP and disaster recovery purposes but the server assignment is done by each server itself according to the role of that particular server.

[...]

A nice oneliner I found here will list all available COM object for your machine:

gci HKLM:\Software\Classes -ea 0| ? {$_.PSChildName -match ‘^\w+\.\w+$’ -and (gp “$($_.PSPath)\CLSID” -ea 0)} | ft PSChildName

I had a need for translating Active Directory object names from any to any form. For instance lab\administrator to cn=administrator,cn=users,dc=lab,dc=local and back. I remembered having seen a cool function called NameTranslate somewhere to see if I could use it somehow.

When searching the internet I found some vbscript code which created an object called “Nametranslate”. Since I absolutely hate vbscript I decided to translate this script into a native PowerShell script. First step was to create a new ComObject like so:

[...]

Some things may seem a little strange when working with PowerShell when coming from other scripting languages and especially when coming from a development background. What I noticed today in one of my scripts took me quite a while to troubleshoot.

The problem concerned a comparison between two values using “-eq”. I retieved a value from a subroutine and compared it to a string value. The code looked something like this:

$returnValue = Somesubroutine(xxxx…
if ($returnValue -eq “xxxxxxx”) { do something }

Because of an error in my subroutine the returning value was a boolean instead of a string. Still I wondered why the “do something” was executed. I mean, $True can’t possibly equal “xxxxxxx” right? Try the following on your commandline:

if ($true -eq “blahblahblah”) {write-host “They are the same”}

Have you tried it? The text “They are the same” will actually be written to the console! How weird is that?

PowerShell has a very powerfull typing system. This typing (or casting if you will) will automagically convert the type of an object to an other type if needed. However, PowerShell should only do this IF NO INFORMATION IS LOST.

In this case I’m not sure what is happening. Either the text “blahblahblah” is actually converted to a boolean and since it exists it will be converted to $true. Or, the if statement encounters a “$true” and will then immediatly yield true and execute the command ‘write-host “They are the same”‘.

Whatever is the case: GOTCHA!

At Login Consultants we have created a rather extensive scripting framework based on PowerShell scripts called Solution4. Conceptually it is similar to an earlier version of Solution4 which was based on CMD scripting and a collection of tools. The power of PowerShell, however, allowed us to improve this scripting framework even beyond our own dreams.

One of the key features of this scripting framework is that we standardize the automation and even more important, the way HOW automation is performed. This extensive standardization allows us to automatically document anything we do within this scripting framework. For our documentation efforts we chose Microsoft Word 2007 because it is, or will be, the most widely used word processor and because the COM interface is relatively straightforward.

The code snippets I will post in these series about PowerShelling Word 2007 are the functions I created to create items like paragraphs, tables and headings. At the end of these series I will put the complete script online for download.

First of all, lets get Word 2007 to run from PowerShell. Word 2007 exposes its methods through a COM interface. Starting an instance of Word 2007 in PowerShell is done like this:

$msWord = new-object -com Word.Application
$msWord.Visible = $true

This first line of code will start Word 2007 but it will be invisible to you. The second line will instruct Word 2007 to materialize. While this is already pretty cool, as you can see there’s no document. The next step is to open a new document like so:

$doc = $msword.documents.add()

The document created is based on the default template. If you want to base you new document on a different template, just tell Word. See:

$doc = $msword.documents.add(“D:\GenDoc\gendoc.dotx”)

Next time I will show you how to actually add some text.

Check out this presentation by Jeffrey Snover where he gets back to the basics and then work his way up. Great presentation to quickly understand the how and the why in PowerShell.

Check it out here

Read a very nice summary of the differences between the PowerShell 1.0 and PowerShell 2 CTP3 here

The snippet below will return all computer object is the specified OU. Just replace the LDAP query with the one you want. The “searchscope” property should be set to “subtree” if you want to do a recursive search.

$dirEntry = new-object directoryservices.directoryentry(“LDAP://ou=XXXX,dc=DOMAIN,DC=COM”)
$dirSearcher = new-object directoryservices.directorysearcher
$dirSearcher.searchroot = $dirEntry
$dirSearcher.Filter = “objectclass=Computer”
$dirSearcher.SearchScope = “base” (or “onelevel” or “subtree”)
$dirSeacher.FindAll()