Another post from our ‘customer support archives’. We’ll call this one ‘The case where custom properties were not copied to the converted PDF file and why it was not our fault’.
We were contacted by a SharePoint developer who is using our PDF Converter to automatically convert a file to PDF format as soon as it is uploaded to SharePoint, a common requirement. However, it appeared that the custom properties specified on the source document were not copied over to the PDF file, even though this feature was specifically enabled.
After a brief investigation the following came to light:
On Document Libraries that do not require an explicit check-in, workflows are triggered as soon as the file is uploaded, before the custom properties are filled out.
Filling out the properties directly after the file has been uploaded does not retrigger the work flow.
In other words, the workflow and associated PDF conversion process was triggered before the properties were set so it appeared they were not copied over.
This is all very inconvenient, fortunately there are a number of workarounds that you can apply:
Use the ‘Pause for duration’ workflow activity and periodically re-check if the properties have been filled out. Your mileage may vary as this activity is known to be very buggy.
Change the settings on the Document Library and require explicit check-ins. With this feature enabled the workflow waits until the check-in has taken place (after setting the properties).
Use the 'Wait for field change in current item' activity to pause the workflow until one of the mandatory properties is not empty.
Option 3 is probably the most elegant, but it depends on your exact requirements.
For a tutorial on converting files to PDF Format from a SharePoint workflow check out this blog posting.
I keep running into this problem and wasting hours Googling for the solution, which is why I have decided to write a quick post to prevent the same from happening to others.
The symptoms are as follows: You are installing an instance of MOSS 2007, everything is going well, the account you are using is an administrator in all the places where the account should be an administrator, you get to the bit where you are going to configure the Shared Service Provider and BOOM! access denied.
You double check all privileges, farm administrators, application pool accounts etc, read well meaning advice from other users experiencing something similar, but basically you are not getting anywhere.
Then you hear the faint sound of a 10 pence coin drop (we don’t do quarters in the UK)… didn’t Microsoft introduce some security fix to prevent systems to be accessed using a name other than the machine’s hostname? This machine’s name is someserver1 while the SSP is hosted under portal.companyname.local/ssp/admin.
If it wasn’t for the active SharePoint community, who have filled in the many gaps in Microsoft’s SharePoint documentation, it would be virtually impossible for the developers in our organisation to do any kind of half decent SharePoint development.
Although we have been happily sharing our knowledge and experience on this blog, we feel we have to do something more, which is why we have decided to make our internal SharePoint development guidelines documentation available for download.
Let’s put a big fat disclaimer first: These guidelines have been written with our internal developers, environment and products such as our PDF Converter, URL Shortener and Audit Suite in mind (spot the subtle, yet shameless, plug). There is some valuable information in this document, but not everything may apply to your situation, team or company. Feel free to rip the document apart, rebrand it so it looks like you wrote it, we don’t mind. However, we would appreciate it if you would include a link to this blog posting in any derivative works.
Let’s disclaim a bit more: This is not a SharePoint Tutorial, existing SharePoint development knowledge is assumed, the document is constantly being revised, we don’t guarantee that ANY of the information in the document is accurate, use at your own risk etc. etc.
Now, having said that, this document is serving our internal developers well. I cannot imagine that anyone has memorised it, but it is very useful to read at least once and then use it as a reference to get to the real information.
Over the next few weeks and months we will discuss each section in a separate blog posting to allow an open discussion to take place.
We would like to thank Brian Farnhill for reviewing an early version of this document in early 2009.
Constructive feedback is always welcomed. Either use the comments section at the bottom of this posting or any of the facilities listed on the Contact Us page. If you find this information valuable then please subscribe to our RSS feed and feel free to evaluate our products.
Since we started the beta cycle of the new Workflow enabled version 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 the release version with immediate availability.
For those not familiar with the product, the PDF Converter for SharePoint is a light weight solution (4MB download) that allows end-users to convert common document types, such as doc, docx, rtf, InfoPath, 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 as well as this blog posting describing how to use the PDF Converter from A SharePoint Designer Workflow.
In addition to a number of small bug fixes, the main changes introduced in version 1.2 are as follows:
382
Documents can now be converted automatically from SharePoint Workflows.
522
Experimental support for converting InfoPath documents added.
320
The PDF Converter is now enabled automatically on all Web Applications.
520
Improved detection of WSS vs MOSS. This caused problems on some WSS systems running Microsoft Search Server Express. Click here for a detailed explanation.
Our support team faces different SharePoint based ‘customer challenges’ on a daily basis. It will comes as no surprise that no two SharePoint deployments are the same, but sometimes we are really baffled by what we encounter.
Recently we came across a SharePoint environment that had a problem with the fancy ‘Browse’ button that allows users to select a destination library to store documents converted by our PDF Converter for SharePoint. The thing is, this environment was running WSS and not MOSS and as WSS does not support this fancy feature we only display this button on MOSS systems.
Shiny Document Library picker
Our MOSS detection logic is based on a common pattern, which is to check for the presence of the MOSS only OssNavigation feature. As this particular WSS environment has this feature installed it was incorrectly detected as a MOSS installation, resulting in problems when someone would press the browse button.
Further investigation shows that checking for OssNavigation is not a reliable manner of detecting MOSS as this feature is also installed by the free Microsoft Search Server 2008 Express, which can be installed on top of WSS.
To cut a long story short, we have updated our solution to check for 2 MOSS specific features before deciding if a SharePoint installation is MOSS or WSS. The code is as follows:
/// <summary>
/// Method to find out if a SharePoint installation is MOSS or WSS 3.0
/// </summary>
public static bool IsMOSS()
{
SPFeatureDefinitionCollection features = SPContext.Current.Site.WebApplication.Farm.FeatureDefinitions;
if (features["OssNavigation"] != null && features["Publishing"] != null)
return true;
else
return false;
}
One of the features that was sorely lacking in SharePoint 2003 was the ability to audit the use of SharePoint. Who had opened a sensitive document and leaked it to their buddy at a tabloid newspaper? … no-one knew, not even the IIS log files.
Third parties attempted to address the situation by modifying some of SharePoint’s underpinnings, but this had the unfortunate side effect that Microsoft would no longer support your, now non-standard, environment.
When Microsoft released SharePoint 2007 they announced that they had now ‘ticked the audit box’. And indeed, the platform supports auditing, but most functionality is either completely missing or lacking in functionality, leaving an excellent opportunity for third parties such Muhimbi to fill the gaps.
Today we are announcing the availability of Muhimbi SharePoint Audit, a suite of tools that allow Auditing to be enabled automatically on new Site Collections, Audit Logs to be viewed using a user friendly viewer and Auditing to be monitored using an Audit Monitor. The software runs on both WSS 3 as well as MOSS. For detailed information check out the product page.
Control farm wide audit settings
The product announced today is a Release Candidate (Update: The Official release version is now available). We have put it through an enormous amount of testing on different platforms including Windows Server 2003, Windows server 2008, 32 and 64 bit versions of MOSS as well as WSS and with various language packs. We are very pleased with the results, however nothing beats testing it in the real world so we would appreciated your help before releasing the final version.
Monitor the state of auditing
If you think you have identified an issue then please report it in the relevant forum or contact us directly. When reporting issues please be as specific as possible and include screenshots, event log entries, the version of SharePoint used, the version of our software used and steps to reproduce the problem.
Before reporting issues, please check if is not already listed in the release notes. We will give away a couple of vouchers to those people that report the ‘best’ bugs.
Another post from our ‘customer support archives’. We’ll call this one ‘The case where custom properties were not copied to the converted PDF file and why it was not our fault’.
If it wasn’t for the active SharePoint community, who have filled in the many gaps in Microsoft’s SharePoint documentation, it would be virtually impossible for the developers in our organisation to do any kind of half decent SharePoint development.
