Tag Archives: OWA

“Oi, Admin! you’re not as clever as you think you are!”, or, the importance of doing simple things right.

just had a call from a customer who was having terrible trouble exporting discovery search data to pst from Exchange 2013. The search was apparently running fine, but the download failed with a long error message.


i asked for problem steps recorder output to see what they were doing… (this is from my repro):


if you can spot what they’re doing wrong without reading the error message, well done. have a muttley medal.

this throws the error message:

PLATFORM VERSION INFO Windows : 6.2.9200.0 (Win32NT) Common Language Runtime : 4.0.30319.34209 System.Deployment.dll : 4.0.30319.34274 built by: FX452RTMGDR clr.dll : 4.0.30319.34209 built by: FX452RTMGDR dfdll.dll : 4.0.30319.34274 built by: FX452RTMGDR dfshim.dll : 6.3.9600.16384 (winblue_rtm.130821-1623) SOURCES Deployment url : /microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https%3A%2F%2Flocalhost%2Fews%2FExchange.asmx">https://localhost/ecp/15.0.1076.9/exporttool/<servername>/microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https%3A%2F%2Flocalhost%2Fews%2FExchange.asmx ERROR SUMMARY Below is a summary of the errors, details of these errors are listed later in the log. * Activation of /microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https%3A%2F%2Flocalhost%2Fews%2FExchange.asmx">https://localhost/ecp/15.0.1076.9/exporttool/<servername>/microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https%3A%2F%2Flocalhost%2Fews%2FExchange.asmx resulted in exception. Following failure messages were detected: + Downloading /microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https://localhost/ews/Exchange.asmx">https://localhost/ecp/15.0.1076.9/exporttool/<servername>/microsoft.exchange.ediscovery.exporttool.application?name=ce66od_1&ews=https://localhost/ews/Exchange.asmx did not succeed. + The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. + The remote certificate is invalid according to the validation procedure.

so… what’s wrong there? well, the remote certificate is invalid. fine… but it’s the local machine… the url says “localhost”…. oh… sigh.

they’ve done the standard admin shortcut of going to localhost because they can’t be bothered to type out the unfeasibly long servername, and the client then throws an error, because “localhost” isn’t a subject alternative name on the cert, unsurprisingly. the little red address bar in the screenshot above is a clue, there.

sure enough, when they use the servername instead of the url, everything works like a charm:



the lesson there is “do things right”. localhost will throw errors with https other than just needing to click through a cert warning, so don’t use it. if you are using it, and you get weird behaviour, try attaching to the site with a url that is actually on the SSL certificate.

also, a post script: when it says “if you experience problems, try clearing cookies and signing in again”, why not try clearing the cookies and signing in again, before you ring me up and tell me it doesn’t work? 😀

Why doesn’t webready work the way I want it to?

It will come as no surprise that there are different ways of accessing your mailbox available – some, like outlook anywhere and “classic” outlook, require some level of corporate control over the client device, and some, such as OWA, don’t. if you know your URL and your username/password, you can get your mail anywhere in the world, with OWA. At home. In the pub. In a BoHo café in New York, if that’s your bag.

The trouble with the latter method is that it becomes very easy for the more relaxed user to leave confidential material lying around in the internet cafes and bookstores of the world. Luckily, there’s something you can do about it. By combining the “direct file access” and “Web ready document viewing” settings of the OWA virtual directory you should be able to prevent people downloading documents onto the local machine while they arestill able to view the contents. But there is a little snag. In theory, it should work with JUST the exchange management console settings… disable direct access, enable web ready, force web ready… should do it. Doesn’t.


When you set direct file access in the EMC:



You’re not completely disabling direct file access:



So, if you choose to tell OWA you’re on a private computer when you’re actually on a public computer you get this:



When you should get this:


If you missed the subtle difference, the file is greyed out in the lower example… 😀


But who the hell would do that? Well, users will.

“oh, I can’t download this file…” says Carl the service delivery executive to his colleague…

“just log out, and log back in using the ‘this is a private computer’ setting, silly. It’ll work fine”

Moral of this story – use the shell.


And the filename is greyed out. Hoorah. I’ll not put a picture – imagine one that looks just like the one above. It’s easier.



Does it stop me sending documents? No.



It just prevents me viewing them: