Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a client who uses an application that uses *.fr3 files, which as far as I am aware are nothing more than binary files in a proprietary format. Those files are periodically emailed from the software company to my client. Using Outlook (2003 or 2010) the client can save the attachment and then copy the file to the application that uses them. No problems and nothing unusual so far.

When the client uses OWA (Exchange 2003), even on the same machine, and tries to save the attachments they result in zero byte files. The solution they have employed for those staff members who only have access via OWA has been to ask the software vendor to zip them up and resend them. This works fine as far as the file goes but involves extra steps and bother that shouldn't be required.

I can find nothing to explain why this only happens with *.fr3 files. All other attachments they receive, such as *.zip, *.pdf, *.doc(x), *.xls(x), etc. save perfectly. The anti-virus software (Avast) is not treating *.fr3 as anything special either.

Are *.fr3 files something special as far as OWA is concerned that I'm unaware of? How can I convince OWA to treat them the same as other file types, which all save without issue? This isn't a show-stopping problem but is just one of the annoyances I'm trying to clean up for the client.

share|improve this question
    
It might be worth testing whether it's caused by the contents of the file or the extension by creating a junk binary file with a .fr3 extension and sending that to the client or changing the extension on one of the legitimate files. –  Ladadadada Nov 16 '12 at 12:54
    
I'll give that a try on Monday. –  John Gardeniers Nov 16 '12 at 12:55

1 Answer 1

I had the same problem with OWA 2003 a while back, using a custom extension. Apparently the cause was a combination of no valid MIME type returned by the server, and IE detecting the MIME type incorrectly from the header of the file.

I'm still not sure why downloads were zero bytes (this can happen with XML files specifically, but I haven't read anything about it happening with binaries), but this solved it:

  • Add the .fr3 extension with the application/octet-stream MIME type on the IIS instance that serves OWA. (If you can find a more appropriate MIME type for the files, use it instead -- application/octet-stream is for generic binaries).

  • Follow the steps posted by Brad_Saide to disable MIME handling and MIME sniffing on the client. This is the short of it:

Navigate to the following registry keys:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_MIME_HANDLING
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_MIME_SNIFFING

Modify the DWORD value beside iexplore.exe from 1 to 0 in both areas.

The linked posting does not address zero byte downloads, and says that one or the other solutions (either on the server or on the client) should fix DOCX download issues. I made both changes and it solved my problem; Unfortunately I didn't try making the changes incrementally, so I'm not sure if one or the other would fix it.

Try adding the extension/MIME pair to the server first, and then test and move onto the clients.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.