04-12-2018 08:11 AM
Hi everybody,
Exchange 2010 / EVault v10.0.1.1189
Recently we change url of our owa from https://mail.domaina.com/owa to https://mail.domainb.com CAS servers remain the same, its just the OWA url that has been modified.
Despite of that, when we access the new OWA url, Search archives and Archive explorer are not displayed in the left pane. If we access the old OWA url, the buttons are displayed.
Is there anything to do somewhere on the Exchange CAS servers to allow the new url to display the EV entries?
Thanks in advance
Solved! Go to Solution.
04-16-2018 06:28 AM
Yeah, you are still using the same browser, but nonetheless it is the browser that's the problem. Here's the proof from your log:
13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Checking browser... 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Checking for MSIE in user agent 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Returning: False
Because our OWA extensions are only supported using legacy IE, we check the browser's user agent string for the substring "MSIE" to see if we should enable the extensions. IE 11, when it is not using compatibility view, does not include this substring. If you add a particular URL to the compatibility view list, you will see when you visit that URL that the user agent will change and IE 11 will include the "MSIE" substring, in keeping with IE versions of old.
So what's happened is that you have changed the OWA URL, and you only have the old OWA URL listed in your IE compatibility view list. Thus when you visit the new URL, IE is not using compatibility view, and therefore not passing the "MSIE" version of the user agent string, and therefore our extensions are not detecting it as a compatible browser, and so the extensions disable themselves, and suddenly it seems like the EV OWA integration has stopped working.
Andrew_G_ nailed this on Friday, admittedly without much in the way of explanation. But that's clearly what's going on, and it will start working again once you get IE to use compatibility view for the new OWA URL.
--Chris
04-12-2018 09:01 AM
04-12-2018 11:32 AM
Any chance you changed the EWS URL at the same time you changed the OWA URL? Our OWA extensions start by looking up the user's hidden message using EWS to determine whether the user is enabled for archiving. If that's not found, the extensions assume he's not enabled and don't show any of the buttons. It sounds like that's what's going on here.
You can see the EWS URL used by our request if you collect an OWA diagnostic log as per this article. (The article says Exchange 2007 but the process is the same for 2010.) Look for errors with the EWS request for the hidden message toward the start of the log. If you want help reading the log, you can post it here.
--Chris
04-13-2018 02:48 AM
Hello Chris,
Thank you for your reply. I check the log as suggested and the difference I see, is the entry IsValidBrowser to False when I try to access OWA with the new url :
[EVContext::IsValidBrowser] Returning: False
I attached the log file of the access that does not work if you see something that can help to solve the problem.
04-13-2018 02:51 AM
Hello Virgil,
I do not add a CAS server. It's only the Exchange url that have been changed. I check the web.config and there is no reference to the old name.
04-13-2018 03:12 AM
Sounds like you need to put the browser into compatibility mode for the new URL
04-13-2018 03:23 AM
Additional to Andrews's suggestion:-
If you are running OWA 2010 from non-Internet explorer browser (eg mozilla, safari, chrome..etc) then you expected to see lines “EVContext::IsValidBrowser False”. Verify web browser support in compatibility guide.
https://www.veritas.com/content/support/en_US/doc/128058600-128865835-0/v128055911-128865835
04-16-2018 02:31 AM
Hello all,
I use the same browser and it is Internet Explorer 11 when I make my tests. It's just the url that changes.
Phil
04-16-2018 06:28 AM
Yeah, you are still using the same browser, but nonetheless it is the browser that's the problem. Here's the proof from your log:
13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Checking browser... 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] User agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Checking for MSIE in user agent 13/04/2018 10:04:42 [4172,88] [EVContext::IsValidBrowser] Returning: False
Because our OWA extensions are only supported using legacy IE, we check the browser's user agent string for the substring "MSIE" to see if we should enable the extensions. IE 11, when it is not using compatibility view, does not include this substring. If you add a particular URL to the compatibility view list, you will see when you visit that URL that the user agent will change and IE 11 will include the "MSIE" substring, in keeping with IE versions of old.
So what's happened is that you have changed the OWA URL, and you only have the old OWA URL listed in your IE compatibility view list. Thus when you visit the new URL, IE is not using compatibility view, and therefore not passing the "MSIE" version of the user agent string, and therefore our extensions are not detecting it as a compatible browser, and so the extensions disable themselves, and suddenly it seems like the EV OWA integration has stopped working.
Andrew_G_ nailed this on Friday, admittedly without much in the way of explanation. But that's clearly what's going on, and it will start working again once you get IE to use compatibility view for the new OWA URL.
--Chris
04-17-2018 02:23 AM
Thanks to everyone for contributing and for the detailed explanation.
Phil