Word Automation Services and PowerShell

For one of my clients I wanted to test the Word Automation Service. As you might know, this is a feature of SharePoint 2010 that automatically converts Word documents (.doc and .docx) into other formats. For my client, the PDF format was the relevant one.

Unfortunately, the Word Automation Service is not part of the GUI of SharePoint. Users cannot access it, but developers can create code for this. But I’m no developer! Fortunately, there is a PowerShell script which you can use to test/demonstrate the Word Automation Service.  More on this later.

First of all, just a bit of theory. The Word Automation Service is one of the many SharePoint 2010 services. Its workings are very simple. It uses a dedicated database and timer jobs to convert the documents.

Documents to be converted are stored in the queue database and await the timer job to be picked up. This is nice, because you can use this to track the progress of the job. In my case, the Word Automation Service did not finish, and I was able to look directly into the database to see the process.

The database is named WordAutomationServices_<uniquenumber>. You can look into the table dbo.Items to see the jobs being queued. You will see some interesting items. The name of the document being converted and the name of the new document. But also, the start date, end date and a possible errorcode. This one is very handy!

But there will be no documents placed into this database, if you haven’t got the Word Automation Service up and running on a serverfarm level and when you haven’t activated this on the web application level. But also, you will need to have some code to address this service. This is where PowerShell comes in.

Like I said, I’m no developer. So luckily, there are some very smart people out there who create PowerShell scripts. You can use this script to test the Word Automation Service. It basically tells the Word Automation Service which document to convert and the destination of this document. Save this script as (something like) “convert2pdf.ps1” and run it using the SharePoint 2010 Management Shell.

# Input parameters for the script
$wordFile="http://sharepointserver/documents/word.docx"
$pdfFile="http://sharepointserver/documents/pdf.pdf" 
# Get the Word Automation Service Proxy
$wasp = Get-SPServiceApplicationProxy | where { $_.TypeName -eq "Word Automation Services Proxy" }
#Create the Conversion job
$conversionJob = New-Object Microsoft.Office.Word.Server.Conversions.ConversionJob($wasp)
# Get the web url
$web = Get-SPWeb "http://sharepointserver/" 
# Set the credentials to use when running the conversion job.
$conversionJob.UserToken = $web.CurrentUser.UserToken
# Conversion Job Name
$conversionJob.Name = "Convert docx to PDF"
$conversionJob.Settings.OutputFormat = [Microsoft.Office.Word.Server.Conversions.SaveFormat]::PDF
$conversionJob.AddFile($wordFile,$pdfFile)
# Start the conversion job
$conversionJob.Start()

One tip: the account you are using to run this script needs to be in the farm administrators group and has to be able to write to the content database.

Ok, this script will work. Please believe me, I’m no developer – but I got it up and running. I ran the script and started looking into my document library: nothing. The timer job then? Running smootly. But no PDF’s….Strange. Then I began looking into the database and started noticing the errormessages. All these messages had one errorcode: 65543. This is odd. This errorcode refers to a document being corrupt. It is not!

I will tell you why. After you have implemented SP1 for SharePoint 2010, the Word Automation Services run in Sandbox mode. Don’t ask me why! But the service will run, but at the end: no PDF’s. But there is a way to solve this. Get Word Automation Service out off the Sandbox. And here’s the script to do this:

$sp = Get-SPServiceApplication | where {$_.TypeName.Equals("Word Automation Services")}
$sp.DisableSandbox = $true
$sp.Update()

You will need to run an IISRESET after this. But then: it works!

Enjoy!