cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange OWA url change => No EV Entries in the menu ?

domus
Level 3

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

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

9 REPLIES 9

VirgilDobos
Moderator
Moderator
Partner    VIP    Accredited Certified
Have you added any new CAS server? If so, you need to add its IP to the ExchangeServers.txt file and rerun the anonymous acess script.

Also, have a look on the web.config file on the CAS servers. It's possible that there is some entry referencing the old URL in the EV configuration section.
--Virgil

ChrisLangevin
Level 6
Employee

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

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.

 

 

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.

 

Andrew_G_
Level 5
Employee Accredited

Sounds like you need to put the browser into compatibility mode for the new URL

Pradeep-Papnai
Level 6
Employee Accredited Certified

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

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

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

Thanks to everyone for contributing and for the detailed explanation.

Phil