Using the PDF Converter from a SharePoint workflow

Posted at: 13:02 on 16 April 2009 by Muhimbi


It is always interesting to see how your customers have a completely different look on the fantastic product you have been working on for months. After the initial release of our PDF Converter for SharePoint, the majority of the support calls we received were about how to use the product from a SharePoint workflow. Errrr…… we hadn’t really thought about workflows as it is so un-cool, related to SharePoint designer…and…and…and… actually we had never done much with SharePoint workflows.

As much of our feature set and product development is driven by customer demand, it was time to skill up on workflows and  - dare I say it - SharePoint Designer. And you know what? It is pretty cool!As a result a new, workflow enabled, version of the PDF Converter is now available for download.

What follows is an example of how to create a simple workflow in SharePoint Designer, which converts a file to PDF format as soon as it has been approved. If you prefer to use Nintex Workflow then have a look at this post.

Before you start, make sure the PDF Converter for SharePoint has been installed and you have access to a site collection with the appropriate rights to create workflows. Some basic knowledge about creating and configuring document libraries is assumed.


Create and configure the Document Library

  1. Create a document library named ‘Important Documents’.
  2. Once created, enable ‘Requires content approval’ on the library’s Settings > Document Library Settings > Versioning Settings screen.
  3. In the document library, create two folders: ‘Confidential Proposals’ and ‘Approved PDF Files’.

Create and configure the work flow

  1. Start SharePoint Designer and open the site collection that contains the ‘Important Documents’ library. 
  2. From the File menu select New > Workflow.
  3. On the first screen of the Workflow wizard, specify the following settings:
    • Name the workflow ‘Convert Approved documents to PDF Format’.
    • Select the ‘Important Documents’ list.  
    • When creating a SharePoint Designer Workflow in SharePoint 2013 then please select Platform Type: SharePoint 2010 Workflow.

    • Select the 2nd and 3rd checkboxes to make sure the workflow is triggered whenever a document is created or (its status) is updated.

    • Click the ‘Next’ button to proceed.

     workflow wizard

  4. We are now ready to create the workflow. From the ‘Conditions’ menu select ‘Compare any data source’. This inserts the ‘If value equals value condition.
  5. Click on the first ‘value’ followed by the ‘display data binding’ (fx) button.
  6. Select ‘Current Item’ as the Source and select ‘Approval Status’ in the Field. Click the OK button to continue.
  7. Click on the second ‘value’ and select ‘Approved’ from the list.   

To avoid that the same workflow is executed on the converted PDF file after the conversion has taken place, we need to specifically exclude pdf files as follows:  

  1. Add another ‘Compare any data source’ condition.
  2. Click on the first ‘value’ followed by the ‘display data binding’ (fx) button.
  3. Select ‘Current Item’ as the Source and select ‘File Type’ in the Field. Click the OK button to continue.
  4. Click ‘equals’ and change it to ‘not equals’.
  5. Click on the second ‘value’ and enter ‘pdf’.

With the Conditions in place we can now add the Actions, which is where the magic happens.

  1. From the ‘Actions’ menu, select ‘Convert to PDF’. It may be hidden behind the ‘More Actions’ option.
  2. The following action is inserted:

    Convert this document to this url using the same file name and include / exclude meta data. Store the converted item details in List ID: Variable: List ID, Item ID: Variable: List Item ID.

    Let’s examine what the various options mean:
    • this document:  Specify which document to convert. Select the option and make sure ‘Current Item’ is selected.
    • this url: Specify the location the converted file will be written to. The following options are available:
      • Leave it empty: When no value is specified then the converted document is written to the same folder as where the source file is located.
      • Site Relative URL: By specifying a URL relative to the current site, e.g. ‘subsite/shared documents/PDF Files’, any folder location in the current site collection can be targeted. This is the option we want to use so enter Important Documents/Approved PDF Files.
      • Web Application relative URL: Using a URL that is relative to the entire web application, e.g. ‘/sites/Press Office/Public Documents/To Distribute’, any folder location in any site collection can be targeted.
    • the same file name: The name of the converted file can be specified here. In our case we’ll leave it empty to make sure we use the same name as the original document.
    • include / exclude meta data: In case of sensitive documents we may want to strip any custom SharePoint columns from the file. Assuming that our document library contains a column ‘Yearly sales forecast’, we want to select ‘Exclude’.  
    • Variable: List ID: A new workflow variable named ‘List ID’ is automatically created. After the file has been converted, this variable will contain the ID of the list the converted file was saved to. This can later be fed into another action in order to manipulate this file further.
    • Variable: List Item ID: A new workflow variable named ‘List Item ID’ is automatically created. After the file has been converted, this variable will contain the ID of the item the converted file was saved to. This can later be fed into another action in order to manipulate this file further.
  3. Insert a new action named ‘Log to History List’ and enter ‘File converted to PDF Format’.
  4. Insert a new action named ‘Update List Item’ and click this list. We are now going to automatically mark the converted PDF file as approved.
    • From the ‘List’ dropdown select ‘Important Documents’.
    • Click the ‘Add’ button and set the field to ‘Approval Status’ and the value to ‘Approved’. Click OK. Please note that things have changed in SharePoint 2010, it is no longer possible to set the value of the ‘Approved’ field. For details and a workaround see this thread on our forums.
    • In the ‘Find the List Item’ area set the Field to ‘Important Documents:ID’.
    • Click the fx button next to ‘Value’, specify ‘Workflow Data’ as the Source and set the Field to ‘Variable: List Item ID’. Click OK.
    • Click ‘OK’ again to return to the Workflow Designer. It should look like the image below.


Click the ‘Finish’ button to activate the workflow.


Testing the work flow

Testing the workflow is simple: create or upload an MS-Word file to the ‘Confidential Proposals’ folder, from the context menu select ‘Approve / Reject’ and approve the file.

This will automatically start the workflow and after a few seconds the Workflow status should change to ‘Completed’ as shown in the screenshot below.



Once the workflow has completed, you should see the PDF version of the document in the ‘Approved PDF Files’ folder.


If an error occurs during the execution of the workflow then have a look at the following:

  1. Check the messages on the workflow status screen.
  2. Look in the Windows Event log.
  3. Look in the SharePoint trace log.


Labels: , ,

SharePoint supported languages, culture names and locale IDs

Posted at: 16:44 on 15 April 2009 by Muhimbi


We are dealing with a lot of translation and localisation work at the moment and unfortunately there does not seem to be a definitive list of which languages (and their codes) are supported by SharePoint.

So, we reverse engineered the dropdown menu on the SP1 Language pack download page, resulting in the following table.

Language Name

Culture Name

Locale ID









Chinese (Simplified)



Chinese (Traditional, Taiwan)




























































Norwegian (Bokmål)






Portuguese (Brazil)



Portuguese (Portugal)









Serbian (Latin)
























The Locale ID is important for SharePoint Solutions that deploy to the 12/Template/<locale id> folder, for example custom workflow activity .ACTIONS files.

The culture name is used in the names of resource files.



New release of PDF Converter for SharePoint – v1.1

Posted at: 18:33 on 09 April 2009 by Muhimbi


During the 6 week public beta cycle of the initial release of the PDF Converter for SharePoint we have received a lot of positive feedback as well as a number of bug reports.

Feedback has been processed, bugs have been fixed and we are happy to announce our first (non beta) release with immediate availability.

For those not familiar with the product, the PDF Converter for SharePoint is a light weight solution (2.5MB download) that allows end-users to convert common document types, such as doc, docx, rtf, txt etc, to PDF format from within SharePoint. It integrates at a deep level with SharePoint and leverages facilities such as the Audit log, localisation, security and tracing. It runs on both WSS 3 as well as MOSS and is available in English, German, Dutch and Japanese. For detailed information check out the product page.

The main changes introduced in version 1.1 are as follows:

335 Improved support for documents that use extended character sets such as Japanese.
- Integration with the Muhimbi License Manager.
342 Added support for Forms Based Authentication.
470 Installation improvements on non English versions of operating systems.
331 Removal of GUI based installer. It was not robust enough.
483 More descriptive errors logged to the event log when there are problems with the deployment of resources if the Timer service account is not a local administrator.
481 No longer creating a custom Event Source in the registry and thereby preventing security related errors.
241 Significant improvements in memory usage when converting documents.
366 Improved compatibility with certain kinds of document content.
234 Improved support for Open Office document types.



For more information check out the:

As always, feel free to contact us using Twitter, our Blog or regular email.


Download your free trial here (2.5MB). You don’t even have to register, but we would appreciate it if you did.

Labels: , ,

Displaying MS-Word files in a SharePoint Web Part using TextGlow and Silverlight

Posted at: 18:42 on 04 April 2009 by Muhimbi

Update: This post was featured on the Microsoft Channel 9 5 year anniversary episode (Around 15:35 in the video stream).

When Microsoft released their Office 2007 suite of applications they introduced the new Office Open XML standard as well. This XML standard would be the default format for all their applications and the structure of the files would be made an official ECMA standard.

As this standard is based on XML, the content of - for example - an MS-Word file should be relatively easy to parse and then do something useful with it. Something useful is in the eye of the beholder and James Newton King thought it was a good idea to set a couple of months aside and use it as a showcase for Silverlight 2.0, resulting in TextGlow, a Silverlight control that, you guessed it, can display MS-Word files.

This article shows you how to embed TextGlow into SharePoint and use it to display content stored in a Document Library. It is assumed that you are familiar with the Content Editor Web Part, if not then check out Todd Bleeker’s excellent resource on this topic.

TextGlow TextGlow in SharePoint

OK, let’s get started

  1. Make sure you have a copy of Silverlight 2.0 installed on your system
  2. Navigate to an existing or create a new SharePoint site collection.
  3. Download the TextGlow Silverlight viewer, unzip and copy the TextGlow folder (including the folder) to a document Library named ‘Shared Documents’
  4. Add a new Content Editor Web Part (CEWP) to a page of your choice and set the height to something suitable (I used 700 pixels),
  5. Open the Source Editor for the CEWP and paste in the following code.
    <object data="data:application/x-silverlight," type="application/x-silverlight"
            style="width:100%; height:100%">
      <param name="source" value="Shared%20Documents/TextGlow/TextGlow.Control.xap" />
      <param name="initParams" value="documentPath=Shared%20Documents/TextGlow/Test.docx" />
      <a href="">
         <img src="" style="border-style:none;" />
  6. Save the changes and admire the results of your work.

Please note that TextGlow is a proof of concept only. It crashes (badly) if you throw a document at it that is more than a few pages long. If you don’t like it then you can fix it yourself as the TextGlow source code has been open sourced. Alternatively you can use something more mature such as our PDF Converter for SharePoint and display the resulting PDF file in the Page Viewer Web Part.


A new approach to solve SharePoint’s painfully slow spin-up / start-up time for first request

Posted at: 09:55 on 03 April 2009 by Muhimbi

MrSlowThis article was originally posted on our CTO’s personal blog. Due to the tremendous amount of positive feedback we have decided to update the post and move it to the Muhimbi blog, which has more of a SharePoint focused audience. Please check out our PDF Converter for SharePoint, URL Shortener and other SharePoint products if your find this article helpful.

Ever since SharePoint 2007 was introduced I have been really disappointed with the 2 minute spin-up time of the sites and the 30 second wait when launching STSADM.

How could Microsoft have released this? I thought, What is wrong with these people? Why is there no uproar in the SharePoint Community at large?

The SharePoint community quickly came up with workarounds such as the SPWakeUp tool on Codeplex, but these tools don’t actually fix the underlying problem and are of no help at all when you are developing a project that requires a SharePoint restart between compilations.

Before you continue reading you should realise that there are multiple factors that affect initial load time. There is the ‘loading of the assemblies and associated pre-compilation’ wait time, which can be solved by faster hardware, and then there is the problem outlined below, which may or may not be present in your environment. Read on to find out.

As it turns out this problem does not occur on all SharePoint installations, it only happens under a certain combination of circumstances. Fortunately I have identified the root cause as well as a solution.

Symptoms for STSADM:

  • You start STSADM without any parameters
  • There is a delay of about 30 seconds
  • While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic.

Symptoms for SharePoint sites:

  • You make the first request of the day, or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.
  • There is a delay of about 2 minutes
  • While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today, there is no CPU activity, swapping or significant network traffic.

So, what is going on here? Quite a few SharePoint developers are complaining about this on the Internet - and we even encountered the problem on the training disk images used by a renowned SharePoint training provider - but no-one has a real solution.

After yet another night of Googling around I found the solution in a posting about SQL Server 2005, which appears under certain circumstances to suffer from the same problem as SharePoint 2007. (Note that in my particular situation the problem is caused by SharePoint being slow, not SQL Server.)

The problem is that when loading signed assemblies the .net Framework checks the Internet based Certificate Revocation List. As our servers have, like most secure environments,  no outgoing connections to the public Internet, the connection to times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.

After the timeout the assembly is still loaded and the software works as expected, though very slow every time a new signed assembly is loaded for the first time, which happens a lot. The worst thing is that no entries are written to the event log and no exceptions are thrown so you are left completely in the dark about why your application is so bloody slow.

There are a couple of workarounds, which one works best is for you to decide:

  1. Add to your hosts file and point it to your local machine. Some people have reported success with this, but it didn't work for me. 
  2. Allow your servers to directly connect to If your environment dictates the use of a proxy server, configure it using proxycfg. 
  3. Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard or run the vbscript at the end of this posting to help you out. Alternatively you can manually modify the registry for each account:

    [HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]
  4. Download the CRLs and add them to the server manually (I haven't tested this, but it may work):
    1. Download: 
    2. Add them:
      certutil -addstore CA CodeSignPCA.crl
      certutil -addstore CA CodeSignPCA2.crl
  5. Mark Russinovich has written a detailed post about this problem and provides a 5th option, which involves a manual change to each web application’s web.config file. 
  6. Brett Waring pointed me to an article that describes how to reduce the timeout using  a group policy.

We decided to go for Option 3 (disable CRL check) and life is good again, the improvement is significant.


VBScript to apply registry change:

The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.

const HKEY_USERS = &H80000003
strComputer = "."
Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _
    & strComputer & "\root\default:StdRegProv")
strKeyPath = ""
objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys
strKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"
For Each subkey In arrSubKeys
     objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, "State", 146944

With thanks to Nik Shaw for the script. 

Please read the comments section below, it contains some interesting replies including changes required for the various Windows versions as well as a PowerShell equivalent of the above mentioned VBScript  code.


Relevant links:


Subscribe to News feed