SharePoint is a brilliant platform, but it can be a bit difficult to troubleshoot, especially if at some stage customisations have been made (e.g. installation of locally developed or 3rd party software).
The Muhimbi PDF Converter for SharePoint has been deployed successfully on thousands of servers, however from time to time we get support calls informing us that the deployment of our software has " brought down the entire farm!" Our support staff know that our software is rarely (never say never) the cause of any problems, but the deployment of any WSP file, including ours, can have unexpected side effects. (WSP Files are software installation packages used by most SharePoint products).
In case of problems with the SharePoint farm in general, please check the following. If you are experiencing problems with the PDF Converter itself then see these KB Articles.
"Service Unavailable": During a WSP deployment SharePoint recycles the Application Pools used by the affected Web Applications. Although rare, the Application Pool doesn't always spin up correctly. To solve this, open the Internet Information Service (IIS) Service Manager, navigate to Application Pools and verify they have been started.
WSP is stuck on 'Deploying': See this KB Article.
Almost any other error: The PDF Converter for SharePoint deploys a number of files to the 'SharePoint Hive' (%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12 (or 14, 15). These changes are deployed to the recommended locations and will not overwrite or modify any existing entries (unless someone else calls their software the Muhimbi.PDFConverter, unlikely at best). By default a single line is written to each Web Application's web.config file as well. All these changes are made using the deployment mechanism provided by SharePoint and in-line with best practices.
From time to time we witness problems, especially when SharePoint writes out our change to the web.config file. Based on our experience the most common reason for this going wrong is that previously installed 3rd party applications (or locally developed ones) also registered web.config changes and did not clean up the 'config store' during un-installation (Microsoft's Reporting Service's SharePoint Integration is a common example). Even though web.config changes may have temporarily disappeared, SharePoint will flush them back to the web.config file during a future deployment (e.g. the WSP file that comes with the PDF Converter for SharePoint)
To see what changes have been applied to your web.config during deployment, please use a 'diff tool' ( this one is excellent and free) and compare the current web.config in the problematic Web Application with the backup web.config (The Muhimbi PDF Converter creates a backup of the web.config and adds the current date / time to the file name).