CoNetrix

Blog: XML

I was working on a Symantec Mail Security appliance the other day that was passing a bunch of spam through. The problem should have been easy to fix; the license had expired. All that was necessary was to upload the new license file. I emailed it to myself and opened OWA from a server on the customer network to download the file. When I tried to install it, I kept getting an invalid license error. I called Symantec tech support and they regenerated the license and emailed it to me thinking the license was corrupt. That one worked fine. Hmmm…curious, I tried opening the license file I had downloaded from OWA. No surprise why it wouldn’t work, it was an empty text file. I did some testing emailing that file (unzipped) back and forth from account to account. It wasn’t a spam/AV filter problem. Turns out the problem was that I downloaded the file via OWA having sent it unzipped. With Exchange 2007 SP1 prior to update rollup 6, if a file that contains XML data is attached to a message, the XML content in files is removed when you open or save the attachment by using OWA. The license file was XML content…the one from Symantec support worked because it was zipped. http://support.microsoft.com/kb/950675

Networking, XML, Exchange 2007,
 

A client of ours frequently uses a web application to manage customer data and print various documents in PDF format. Users started to complain that they would try and produce a PDF document that was populated with unique costomer data, but there were 'strange words' (they were actually variable names) where the customer data should have been. Normally when our client clicked the "Print" function from within the web application, the webapp would open a new browser window, then opened a PDF  document with the cutomer info merged into a PDF form. This problem was happening only when users accessed this webapp from a Terminal Server session. A similar behavior was happening with a webapp on a different website as well (also only happening on the Terminal Server). [more]

To use this particular web app, the user has to have a unique certificate installed on their machine. Initially I thought that the XML data was not being retrieved properly due to a problem with the certificate, thus the PDF was being merged with an empty data set. After confirming that the certificate was in order, I spending a significant amount of time investigating the Permissions and Trust Manager settings within Acrobat Reader 7 on the Terminal Server. Editing these settings did not alter the behavior of these webapps.

About the time I was considering a re-installation of Acroat Reader on this Terminal Server, I noticed within Acrobat 7's "Internet" preferences a check box labeled "Display PDF in Browser". This option was checked (as it should have been) but I decided to toggle this setting off, apply, then toggle it back on, and apply. This restored the web apps XML-PDF form merging functionality. It appears that the PDF form was unable to access the XML data from the IE pop-up window that initially launched the PDF document. It is still unknown why this particular Adobe setting stopped being enforced (when previously it WAS being enforced). The broken functionality did not coincide with any system event. The web app techinal support team was unable to explain WHY this happened, but they did confirm that they had seen this happen before. The moral of the story... even if everything looks correct on the surface, that doesn't mean it really is.

General, XML, PDF, Acrobat Reader,