IE Process mode gives http://event popup


Most Unified Service Desk customers today utilize the Internal WPF setting for CRM Pages and Standard Web Applications but there are distinct tradeoffs when using this setting in that it utilizes the WPF WebBrowser control for hosting URLs and there are some rendering differences between it and standard Internet Explorer. Another important point about the WebBrowser control is that all the memory that would normally sit in an IExplore.exe process, now lives inside your UnifiedServiceDesk.exe process. This has the effect of making it appear as though Unified Service Desk utilizes a lot more memory than it actually does. There is another way to host the browser built into USD 2.0, however, and that is called IE Process mode.  Generally the guidance is to make sure that a specific web application (such as CRM) utilize only Internal WPF hosted controls or only IE Process hosted controls. This is because they are treated as separate sessions and use of both may cause an additional authentication step to be required that would otherwise be unnecessary. 

 

So, suppose you decide you want to take advantage of the IE Process setting and so you switch your CRM hosted controls to utilize this setting. One thing you might notice right away are some http://event popups appearing with no content all over the place.

These popups are part of a mechanism that USD uses to communicate command and content from a web page back to USD for processing. This happens because when these popups occur in IE 11, it checks the security zone of the popup, and if the security zone the URL lives within happens to be in a zone where protected mode is NOT set , IE will not notify the hosting application about the event and will not allow USD to act on it.  This URL happens to live in the Intranet zone by default, which also happens to have protected mode off by default. 

To resolve this, the easiest solution is to simply turn on protected mode for the Intranet zone.

While this is the easiest solution, there are also other solutions. The end result needs to be that these popup URL’s need to be part of a zone that has Protected Mode turned on. Since you can’t add URL’s to the Internet zone, you can add these URL’s to the Restricted Zone instead, which has Protected Mode turned ON by default.  Here are the standard URL’s that should be added to your Restricted Zone.

1) http://event

2) http://close

3) http://uii

Note that while this will work for standard USD internal events, if you have an actual intranet application that pops windows that you want to control with USD, you must similarly ensure that you also add these to an appropriate zone with protected mode on, or plan on it popping out.

 

 

Comments (13)

  1. Damon says:

    Great info. Just saved me a lot of investigation. Thank You.

  2. Scott.B says:

    Thanks very much for this. Perfectly explains what’s going on.

  3. Hi ,
    We don’t need to add all above URL s at Restricted Zone ,if you are using latest USD release 2.1.1.562. I have tested every thing and it was working fine. Moreover I have unchecked Enable protected mode .

  4. vaneet says:

    Hi Guys !

    Can anyone tried to trace me the reason of below mentioned problem :

    1.) When I am trying to load a particular URL (http://10.216.9.165:8090/systemcommon/jsp/IVRLogin.jsp) on IE Browser, its loading perfectly fine on all the computers.
    2.) When I am trying to load the same URL in USD, It loads fine on some computers only ( on other computers where its not working, in USD just a blank tab is opening ).
    3.) I am using the scriptlet to pass parameters from the CRM “case entity” form on external URL.

    Here is the Scriptlet which includes URL:

    function ProperoSearchPage_Case() {
    var policyNumber= “”;
    policyNumber= “[[incident.tec_useridemail]]”;
    var url=””;
    if(policyNumber!=”” )
    {
    url= “http://10.216.9.165:8090/systemcommon/jsp/IVRLogin.jsp?userId=”+ policyNumber;

    }
    else
    {
    url= “http://oms.religare.com/”;
    }
    return url;
    }
    ProperoSearchPage_Case();

    Any Comment !!!

    Thanks for your support !

    1. JaymePechan says:

      Make [[incident.tec_useridemail]] optional by adding the + operator as in: [[incident.tec_useridemail]+]. If you don’t do this, then if the field is null it will not execute this script and will return blank.

  5. Srikanth says:

    Thank you very much, you saved lot of time for me .. Is this because of “IE process” Hosting type ? Why all of a sudden MS decided to shift all the base config data to IE Process ?

    1. JaymePechan says:

      Yes this is the IE Process hosting type. With this setting, IE and USD run as separate processes, which is why this comes up. No particular reason on the change in the samples. They are meant to demonstrate concepts. You can feel free to switch them to Internal WPF with a bulk edit operation if you wish.

      1. Srikanth says:

        Thanks Jayme, Going though the MSDN documentation on this. A real QQ: is it a new control created by USD Team specifically for USD or Are they using local computer’s IE ?
        Why I’m asking is, some of our websites behave a bit differently in different versions of browser, so will it be the same case while using USD or as it is the same “control”, it will render in the same way for all users?

        1. JaymePechan says:

          When you select IE Process, it uses the actual Internet Explorer browser and attaches the window to USD. When you select Internal WPF, it uses the WebBrowser control from .NET, which, although it still is IE, it has some rendering differences.

  6. vaneet says:

    Thanks jayme for reply !

    But still its not working ! can it is because of internet browser i.e. IE settings

    Please revert

  7. vaneet says:

    Hi Folks,

    I found a workaround of this issue discussed in the previous comments, as I said that this particular URL is a popup URL which is when put in the IE browser & click Enter then IE browser opens that URL in the form of pop-up in another Window.

    Here is the URL :http://10.216.9.165:8090/systemcommon/jsp/IVRLogin.jsp?userId=Tecturamscrm@ext.religare.in

    When i click on that USD button (which is need to trigger this URL), its opened a blank tab for me. Somebody suggested me to use CTRL. + N command which actually opened that particular URL into IE browser. So now 1.) the user first needs to Click that Button in USD. 2.) It opened a blank tab for them. 3.) Then they have to give “CTRL.+N” command; which resultant into opening that URL in IE Browser.

    But Now the no. of Clicks increase which resultant into overall AHT increase.

    On two of the Client’s machine, this work fine as when a user clicks on that button on USD it automatically opened that URL on IE browser (No window navigation rule is created to Show this URL outside the USD boundary). This is very much suspected that IE settings is creating issue here but to find them is a real challenge. I tried comparing IE settings of laptops where its working (i.e. two of those, Client’s machine) from where its not working but couldn’t find yet. Do u know about any such IE settings ?

  8. Rajeev says:

    I really wish there was a separate IE exclusively for USD which could be controlled the way we want. This ShDocview based IE hacking has given my customer more pain than gain.

  9. Srikanth says:

    I don’t know why, some how this setting is not working in my new Win10 laptop !! Any one, any clues ??

Skip to main content