When running a report and downloading it to Excel from the website url, it opens a blank file. However, when going directly to the app servers and downloading the report in Excel the file opens as expected. Any ideas on what could be the issue?

This message has been edited. Last edited by: <Emily McAllister>,

Search for Windows issue on MSDN, espacially if you are under Windows 10 (it's a known issue using IE) and look at your Client redirection setting (many post on subject).

Instead of clicking on Open from Windows security popup, click Save then Open on second popup.

Try saving it first and then open it.

August 8, 2016
WebFOCUS EXL2K and EXL2K FORMULA (HTML-based) XLS Files No Longer Open After Applying Microsoft Security Patch MS16-088
Microsoft® has issued a security patch (MS16-088) that that prevents Excel® 2007, 2010, 2013, and 2016 from opening XLS files generated by the WebFOCUS EXL2K and EXL2K FORMULA formats.
See Microsoft Security Bulletin MS16-088 for details pertaining to each Office release.
As described in Microsoft's Fixes or workarounds for recent issues in Excel for Windows dated July 2016, when you previously tried to open an HTML file with an .XLS file extension from an untrusted location, Excel would warn about the mismatch between the file extension and content, but would still open the workbook without Protected View security. After the security updates, Excel no longer opens the workbook because these files are not compatible with Protected View, and there is no warning or other indication it was not opened. Excel shows a blank screen instead of a more helpful error message with information about what to do next.
Information Builders strongly recommends converting WebFOCUS EXL2K and EXL2K FORMULA procedures to WebFOCUS XLSX (EXL07) and XLSX FORMULA format, which will open in protected view when untrusted. If you continue to use the WebFOCUS EXL2K and EXL2K FORMULA formats, the following workaround has been identified by Information Builders to allow the workbooks to open in Excel. Future security updates from Microsoft may render it obsolete.
When using an Internet Explorer® (IE) browser, save the workbook to your local disk prior to opening it because your local disk is considered trusted by default. Files opened from the Internet, UNC paths, or mapped drives are not considered trusted by default. This is not an issue when using non-IE browsers (such as Microsoft Edge®, Google Chrome™, and Mozilla Firefox®), as they download and save files locally before presenting them to be opened.
Note:
In the WebFOCUS Client Redirection Settings, the Save Report option controls whether the report is sent to the browser inline or as an attachment. In Release 8.1 and earlier releases, the default setting is no, and it sends the report inline to the browser. In Release 8.2, the default is yes, and it sends the report as an attachment assigning a filename. The filename assigned can be specified in the request (FEX) PCHOLD statement using the AS name option.
You can verify the WebFOCUS Client Redirection Settings for EXL2K and EXL2K FORMULA for your installation using the WebFOCUS Administration Console Configuration option. The WebFOCUS Extensions for the EXL2K and EXL2K FORMULA formats are XHT, XHM, and XLS. For additional information on using the WebFOCUS Administration Console to verify and set the Redirection Settings Save As option, see the WebFOCUS Security and Administration Guide for your release.
Related Resources
• TM4750: WebFOCUS Reporting and Microsoft Office Support
• WebFOCUS EXL07/XLSX Format Supported Features Release Roadmap

Thank you Matt, great information. The issue has been a result of recent patching.

If converting to EXL07 is not an option for you and if your users are allowed to changed their excel trust settings, the workaround below allowed us to open EXL2K even with the recent security changes.

1. Open Excel
2. 'File'
3. 'Options'
4. 'Trust Center'
5. 'Trust Center Settings'
6. 'Protected View'
7. Disable the setting for 'Enable Protected View for files originating from the Internet'

Also suggesting

8. Disable the setting for : "Enable Protected View for Outlook attachments"

And ask your network admin to add that "setting" in a GPO, that way everyone in the company/domain will have the fix.

quote:

XLSX

Converting to XLSX didn't fix the issue, tried a few things and changed some settings. However the only option that seems to work is the workaround from GrileS.

I just went through this same issue. The XLSX only works after you change the following client configuration setting (or put SET EXCELSERVURL = '' in your program): From the Admin Console: Configuration/ Client Settings/ General/ IBIWF_excelservurl to blank (remove whatever you have there and just leave the box blank).

**WARNING**: We are on 8.0.09 and did not have the Gen42 patch installed yet. If this is the case for you, do not make the above configuration change through Admin consol. This will trigger a bug whereby the Admin Console also changes another configuration (IBIWF_language) from the correct value of 'en' to the incorrect value of 'EN'. Because our repository database is defined as case insensitive, when you try to save a program change (in Dev or App Studio), you will receive an 'Unable to save file....' error -- underneath it is getting an SQL duplicate key error. So either just use the SET EXCELSERVURL = '' within your program for now or edit the following config file manually:\WF\ibi\WebFOCUS80\client\wfc\etc\cgivars.wfs to be:

IBIF_excelservurl
IBIF_excelservurl =

FYI
As I've been testing the output to XLSX, I've noticed two things that are different:
1) Any column header multiple line formatting is lost. So if you have: ... AS 'Line 1,Line2' it prints all on one line. The old EXL2K format could handle this.
2) Data with non-printable characters in it corrupts the data such that when you open the spreadsheet all values in char columns are lost.(My numeric data displayed, just none of the alpha-numeric. My first two columns had data with non-printable characters in just two of the over 100,000 rows being retrieved and displayed). The old EXL2K format did not have this issue. When I corrected the two errant records, it was able to open and display properly.

This is with 8.0.09.