NEIL PARKHURST

All browsers are pretty much the same thing, right??? The actual answer to this question is a resounding no! When working with Microsoft’s Unified Service Desk (USD) selecting the “correct” browser for your hosting type can make the difference between a solution that’s fit for purpose and one that is slow and unreliable.

Or put another way, your browser choice can be the difference between a project failing or succeeding! So, what are our options and what might influence your choice? In this post I’ll explore the various browser options and give my opinions on best practice. All of the information stated is available in the Microsoft documentation, I am simply presenting it in a single post and giving my views on how the options compare. (Links to the associated Microsoft technical information are provided!)

In recent versions of USD Microsoft have expanded the number of browser options available, so what previously had been an easy choice is now more involved. Our options include;

• Internal WPF
  
• IE Process
  
• Edge Process
  
• Chrome Process (Currently in public preview)
  

Whatever browser you opt for, one tip I have is to select your intended browser at the start of your project. Then complete all development and testing using it, taking care to ensure your development environments mirror the configuration of production. That way you will help uncover and resolve any issues prior to live deployment. Also, if you do change from one browser to another be aware that a level of regression testing will be required!

I say this as browser choice can give slightly different results in terms of how your configuration behaves, pages are rendered and importantly how your solution performs. Completing all testing using your intended configuration should help reduce the risk of any shocks post deployment.

Let’s begin with ruling one option out! I do not recommend using Internal WPF. I would go as far as to encourage Microsoft to deprecate Internal WPF ….

In the early days of USD maybe WPF was a realistic option. Very occasionally I’ve seen a reason to use USD’s internal browser when other options like IE aren’t available. But now we have multiple browser options, meaning resorting to Internal WPF should never happen. I feel the WPF option to be slow, wasteful of memory and may not render pages as expected. In my opinion it should be avoided. (Although I would be interested in hearing about any use cases that suggest a valid reason to implement Internal WPF.)

Warning: This post includes my preferences. You may have different experiences to me, the views expressed here are just my opinions. Microsoft’s official guidance could differ from the personal opinions I express here!

IE Process

Until recently IE would have been my only recommended browser choice. I have found it to be significantly more reliable and faster than Internal WPF.

IE Process handles memory better than WPF and the usdmp.exe
process uses the ProcessTerminationThreshold option to monitor processes. Keeping USD responsive if a single browser “tab” fails.

In some circumstances IE may still be the preferred option.

Getting your IE options correct has been a historic challenge. For example, protected mode needs to be enabled in all security zones. Failing to do this can result in USD behaving in some unexpected ways. (Such as sessions not opening correctly.) A common support issue has been that some (or all) of the agents report unexpected behaviours resulting from IE options. Although these days we do have the best practice analyser which will check our config and suggest revisions to IE options. If you haven’t used the best practice analyser I strongly recommend you look into it. (Regardless of your browser choice.)

The introduction of the InternerExplorerPooling
option did give IE a performance gain. Although I have observed some reliability challenges. I do recommend enabling the IE Pooling option. But if you experience any strange behaviours, including ribbon bar buttons not displaying as expected try disabling it! To be honest I have routinely enabled IE pooling for demonstrations but in production scenarios I have reluctantly needed to disable it.

We can not ignore the fact that IE is an aging browser, it has been around for many years and whilst very robust some newer web-based applications are now unsupported. Generally speaking this hasn’t presented me with any production issues but as time marches on I expect the age of IE to become an issue.

You can find additional information about IE Process here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/ie-process?view=dynamics-usd-4.1

Edge Process

Edge certainly ticks the box of being a newer browser than IE and does have some potential performance benefits.

I have attempted to create some statistics giving a meaningful comparison between each browser option. But any timings are very subjective as many other external factors influence the results. But I can say Edge does “feel” faster than IE. But (in my experience / opinion) by a relatively small margin. I have already commented this post is my opinions, your experiences could differ from mine!

Edge is only supported on Windows 10 versions later than October 2018. In my test environments this doesn’t represent an issue and I have been happily using Edge for some time. But production use may present different challenges … I’ve seen thin clients commonly deployed in contact centres that would be based on Windows Server operating systems or often the hardware (and therefore operating system software) can be “mixed”. It maybe quite common for some agents to be working with aging kit. In these scenarios using the latest windows 10 desktop operating system may present challenges. Obviously, this is a challenge that can be addressed by upgrading your infrastructure but that might be costly!

The elephant in the room with Edge is that Microsoft has announced an intention to redevelop it to work on Chromium. (You can see the announcement published by Joe Belfiore, Corporate Vice President of Windows below.) Obviously, I don’t know the future implications for Edge with Unified Service Desk …. but I do know that fully testing a contact center application can be a significant task. Meaning if you do implement Edge be aware of the potential for future rework. Additionally this would suggest using the “Chrome Process” may be more future proofed. (Again just my opinion!)

Edge (and Chrome) include a limitation that neither support multiple tabs. (At least not currently.) If you absolutely require the multiple tabs feature, then IE will currently remain your browser of choice. I’ve found multiple tabs useful when agents what to do things like repeatedly review old cases or closed activities. I use them to load a form once and allow agents to quickly swap back to the record without needing to reload the form. With IE this might be considered a big benefit but Edge (and Chrome) render the pages faster in the first place, so in my scenarios ditching multiple tabs in preference for general performance gains has been a no brainer.

You can find out more about using the Edge browser here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/edge-process?view=dynamics-usd-4.1

Chrome Process

Chrome is available in USD 4.1. Currently it is available for public preview as part of the insider program but should be available more generally “soon”. (as of March 2019.) Obviously, Chrome maybe on general availability by the time you are reading this post! But even if isn’t, I’m already aware of some people implementing Chrome for production purposes.

For me, the key advantage of Chrome is that it will work with any operating system. I have also found no issues to worry about in terms of Chrome settings. Additionally, Chrome is noticeably faster than IE or Edge.

Its possibly a little early to fully comment on Chrome’s reliability (Chrome support being relatively new!) …. but so far I haven’t experienced any significant issues. And I’m happy to use it.

You may however need to make some tweaks to your USD configuration! Chrome runs scripts asynchronously, I guess this is one reason its fast! But it does mean any RunScript actions may need to be reviewed. If you have a RunScript action that immediately uses the result then you may need to add an ExecuteOnDataAvailable action to delay processing. My configuration contained multiple RunScript actions but even so the required changes only took me a couple of hours. A small price to pay for the level of performance benefit.

Like IE, there is an option to implement chrome browser pooling. This may be enabled by default and does result in a noticeable performance gain. But I have experienced a few related reliability concerns. I believe Microsoft are working on any issues, therefore I recommend you ensure your using the latest version of USD! I suggest initially testing with pooling enabled but if you hit any issues disable this feature and try again! (My issues included challenges with the display of toolbars and refreshing of Dynamics 365 forms.)

Tip:
Having suggested you should consider disabling ChromiumBrowserPooling, each time there is a new version of USD I also suggest re-testing. As I expect any reported issues will eventually be resolved. And you do want to enable pooling as the performance benefits are significant!

Chrome zoom level may also need to be set. I personally found the default zoom level “not ideal”! For me adding a zoom of 0.4 resolved the issue. I haven’t tried this in a production setup, yet! One query I have is that the zoom level will be common to all users. Whilst some contact centers will have a consistent set of hardware this is very often far from the truth. In an environment with mixed screen sizes / resolutions we may need to experiment to see how well this zoom option works. I haven’t actually experienced any issues but you may want to ensure any testing includes all of the resolution options you need to support. (Just to be safe!)

So Chrome is new and as we’d should expect has some limitations. I know this might be sounding a little bad for Chrome! But the performance gains are so significant I am more than prepared to recommend Chrome. It is now my go to USD browser.

You can find out more about using Chrome process here … https://docs.microsoft.com/en-us/dynamics365/customer-engagement/unified-service-desk/chrome-process?view=dynamics-usd-4.1

Conclusion

I did say this post was my opinion … your experiences may differ from mine! If they do I would like to hear about them.

In my opinion ….. my first choice of browser (from now onwards) will be Chrome. And if anything prevents that I will revert back to IE. I will not be using Edge or Internal WPF.

I have nothing against Edge and agree it is a useful option. But I simply favour Chrome. This is largely because of the longer-term roadmap for Edge and its move to become Chromium based. Plus, Edge only working on specific Windows versions is a deal breaker for some contact centers.

So that’s it then (in my opinion, the answer is simple) … if in your contact center you want the most reliable / established USD browser, use IE Process. (For now.)

But If (like me) you want the fastest possible experience and to have an eye on the future then use Chrome. For me, Chrome is the “winner”.

As I have said, several times, this is just my opinion ….. if your opinion differs I’d be interested to hear your experiences.