Now here are the error messages: If I try to delete from the OWA landing page I get this error "Some items can't be deleted. They were either moved, already deleted, or access was denied." My only option here is an "OK" box. If I double click the message and then try to delete it says "502 Bad Gateway" with the same "OK" box.
If I connect to OWA internally everything works fine. If I try to get to it from the outside then I get the errors mentioned above.
From: Lancashire, UK
Well it isn't Mr Shinder but...
You are using disimilar urls for the public (ISA)and private (internal) sites and you haven't ticked 'send the original host header' in the web publishing rule. Do this and alter the host headers on your owa site to relect this.
Link translation won't work because in the delete and move operations of owa you'd actually need the translation to be applied to the INCOMING traffic! It doesn't do that, though you will have found link translation helped some other problems.
Don't think that because you entered a different address in the Web Publishing rule's 'redirect' box that this must also become the host header. The host header and this dns lookup name (that's all it is to ISA) are quite distinct from each other.
Sorry but I'm going to have to correct you on this one. There are multiple host headers and that is how I can test internal and external. The "send the original host header" checkbox IS checked.
As far as the Link translation goes, you are incorrect on this one. The whole purpose of Link Translation is to translate Incoming requests. You can read about this here "http://www.microsoft.com/technet/Security/prodtech/isa/isafp1/ltw.mspx"
As far as the host headers go this does not apply to SSL connections. They can not read host headers. It goes by the IP address that the domain name resolves to.
I appreciate the effort on this issue nonetheless.
From: Lancashire, UK
Okay, I presumed too much with "you haven't ticked 'send the original host header'", I guess there are other ways to see this problem.
When I was working on this I concluded (but never proved) that the owa client sent the link of the object you are deleting or moving in the request to the server; after all, that is the only information the client will have about the object. The link will of course have a fqdn. If you break that fqdn from what the owa server is expecting, it wont find the item you want to delete or move, or might even report it being on a different server. Awkwardly put, but I hope you can grasp what I'm getting at.
One way to break this 'matching up of fqdns' is to not tick 'send the original host header' in the circumstances I stated. In your situation I'd guess you are doing something with the link translation that is having the same effect.
And on the subject of link translation: Nothing in that article says link translation applies inbound (i.e. to client requests). Why should it? I think you misinterpreted what I said. Link translation is only applied to the server response as stated in the article:
"When a client requests an object from a Web site protected by ISA Server, ISA Server checks whether the request is allowed. If the request is allowed, ISA Server retrieves the requested object from the Web server. Before returning the response to the client, ISA Server performs link translation..."
At least we seem to be in agreement about the interaction of SSL, host-headers and dns names
But if this is an owa delete request and ISA changed the host-header and/or ISA mucked about with 'abc.com/gobbledygook' using link transation on the page this request came from, it's broke! (WARNING: don't take this to be actually what's going on in owa - it's a guess - but working to make it all match again makes the problem go away!).
Any clearer or am I just digging a deeper hole for myself?
From: Lancashire, UK
Right, I have a better answer to this one!
I reproduced the error by having ISA change the port to 81 and correct the owa server's response using link translation. Snooping the traffic (with SSL off) between ISA and Exchange showed 'unauthorised' and 'bad gateway' responses. The traffic is, as I suggested, far more complex than my simplistic explanation in previous posts, though I was surprised to see '81' crop up here and there despite link translation!
The error is exactly the same error as I experienced by having ISA change the host header.
Without tackling the inner workings of the OWA code I think I can safely say:
"OWA does not support ISA Link Translation"!
On a similar line: If you attempt to use SSL to HTTP bridging with OWA and use link translation to change http -> https, it will fail. FP1 (and hopefully ISA2004) fixed this situation but ONLY if you used the 'Publish OWA Server' wizard, and it DIDN'T use link translation! Who knows what MS did to make this work; I doubt it can be turned to this problem because whatever it is isn't configurable (or is it?).
Presuming you have ISA on twin-homed server, there is no reason not to have this co-located site on the interface other than the one ISA has listeners bound to. Or, you could create new IP addresses that won't be bound by ISA. SSL to HTTP bridging could be used to allow host-headers to be used to find the correct site. I'm sure there are many other work-arounds, so there is no reason to use link translation in this situation. Therefore, no problem.
From: Lancashire, UK
URLScan might cause a similar problem but wont solve this one. I never installed URLScan on the ISA or IIS servers used to replicate CM's problem. I believe Link Translation will always interfere with some of OWA's functionality (drag-drop, delete, etc.).
Tom's link explaining the http->https fix proves there is nothing here that might offer a solution to ISA redirecting OWA's port numbers either.
I've seem to have the same problem as discribed here. I have an ISA 2004 (4.0.2165.610) Publishing a OWA.
The problem my users are having is when they try to delete objects.
When they have the first view of Web Access up, mark an e-mail they want to delete and press the delete button they get, roughly translated from swedish, "Cannot delete certain objects, Either the object is moved or allready deleted, or access was denied".
And when they open an object and try to delete from inside the object they get: "502 Bad Gateway"
The ISA server has an add-on from Collective Software called Flexauth to handle SSO for diffrent webapplications.
I have the same thing happening using ISA 2004 with Link Translation configured for Exchange 2003 OWA. Any tips would be very welcome. I have worked through a string of problems getting this running and this seems to be the next hurdle.
I contacted Microsoft about this issue, but then, my customer changed their mind about that was the reason we needed to use Link translation on OWA. (Witch was rather good cus my MS contact where in Dubai and their weekend is on Thursday and Friday and I had Saturday and Sunday witch gave 3 days per week to work on the issue :P )
I have the archived correspondance with Microsoft about this at work, but when i try to remember what it was i think it was something about "SSL-offloading". You have SSL to the ISA but HTTP from the ISA to the OWA it self?
If you want to I can try and find the correspondance with MS sometime when im around my workplace?
Thanks for the response. I am not bridging to HTTP it is sent to HTTPS which is published using a different port than 443. I would like to see whatever you have as it may give me a clue to solving the problem.