Friday, September 10, 2010


the other day we had a need to save an HTML file as DOCX. We are creating the HTML file using ConvertT0-HTML. The file contains data that needs to be saved in SharePoint and needs to be editable by others. We decided to save as a DOCX because those in management all have WORD installed but don't have a  Dedicated HTML editor. So here is the Code Enjoy.

!!! YOU MUST HAVE WORD 2007 or 2010 INSTALLED !!!!!

function ConvertTo-DOCX{

#int the the enum returns for DOCX format
$SaveAs = 16

#Create WORD object and perform conversion
$Word = New-Object -ComObject Word.Application
$OpenDoc = $Word.Documents.Open($In)

#stop all WORD instances
Get-Process | Where-Object { $_.Name -eq "WINWORD" } | Stop-Process -Force

Monday, May 17, 2010

5th Silicon Valley Code Camp Oct 9th and 10th 2010

CodeCamp at FootHill College.  Click Here for Details and Registration

I will be giving a session “Advanced Scripting with Powershell” and My co-worker SPowser will be doiing “Powershell Modules” come and enjoy, Its free and lunch is provided. It will only cost you a weekend but why not hang with geeks and further you knowledge.

Sunday, January 10, 2010

Remote Registry PowerShell Module - Shay Levy

This Module Contains lots of cool advanced functions to manage registries on local and remote machines check out Shay's post here...
Remote Registry PowerShell Module - Shay Levy

Sunday, January 3, 2010

A Couple Annoyances in Powershell V2.0

I love Powershell I have written thousands of lines of code in it. I have used most of the great new features that were introduced into v2.0 but I have came across I couple of things that just annoy me. The first is that powershell provides lots of built in or automatic variables one of those new to v2.0 is the PsScriptRoot variable. You would think that with this name it would give you the Root of the Script that is running….Well sort of it only works in psm1 or module file. Why is it not $PsModuleRoot then. Finding the root of the script executing is a common action and it was nice to include this variable but why not for any executing powershell so I am left to keep using $MyInvocation.$MyCommand.Path for this purpose. The second little irritant is the fact that if you define params that are of type switch or bool and their value is set to $false (even if you explicitly set their default value) they do not appear in the $PsBounParameters collection. This suck in the case that you want to use that collection as an object initializer i.e. ( New-Object SomeObject –Property $PsBoundParameters ). In this case the bools on the object don't get set to false which is not really an issue unless the Object is PSObject and you are creating the Property Name/Values on the Object then the name and values don't even get created on your PSObject. Not Sure why the decided not to have the values appear in the $PsBoundParameters collection but makes code messier by having to define the complete hashtable with names and values of the switch or bool that is being used to initialize the Object.   That said Powershell rocks and these can be worked around just seems like odd design choices to me.

Get module Info for a Function in Powershell v2.0

This one liner will return the the module info in a easy to consume format. The info includes the full path to the module that the function is defined in. Good Time and Get-Command!!!

Get-Command -CommandType Function -Name Control-FPService | Select-Object -ExpandProperty Module | Format-List