To Roam or Not to Roam: Web Browsers, Caches, and Environment Manager
This blog is brought to you by Pete Jones, a leader of one of our Ivanti One partners, Avanite. He goes by various names such as “Dr. Jones” and “that guy who knows everything there is to know about Environment Manager". Take it away, Pete, and thank you for sharing your thoughts!
I often find myself in conversation around the question of whether it is the right thing to roam a user’s browser data/settings. The first thing here is to be clear on what is meant by the term “Browser Settings”. By this I mean data associated with web browsers such as browsing history, cookies, DOM data, and other elements that ensure a consistent user experience is achieved as if using a local profile.
In the case of Environment Manager (EM), there are built-in settings to handle this for Internet Explorer, Mozilla Firefox, and Microsoft Edge. Templates from the Ivanti community can also be downloaded to handle Google Chrome.
For Internet Explorer, there are Windows Settings Groups which can be selected to handle Personalization. It even includes settings for anyone still using IE9:
When using these built-in templates, the Environment Manager agent has special logic to ensure these Windows Settings Group work in the desired manner, releasing locks on certain files during logoff and restoring files during logon using an optimized process.
There are also Application Groups related to Internet Explorer, Mozilla Firefox and Microsoft Edge which can be used for Personalization:
Speaking with Ivanti Professional Services, they recommend using a Windows Settings Group to personalize Mozilla Firefox rather than the built in Application Group template. This can be achieved easily by cross referencing the built-in template.
For Google Chrome the previously mentioned template can be used to create a Windows Settings Group to provide personalization:
All the above-mentioned templates can of course be modified to be appropriate for the environment they are used in, and settings may be included or excluded depending on your requirements.
So, we know how to do it, but should we?
As browsers are fairly complicated the decision whether to personalization all the browser settings need to be considered carefully. This often leads to a “do I” or “don’t I” conversation which often comes down to finding a balance between the user experience and the impact on the IT department.
If a decision is made to incorporate browser settings into EM Personalization, then this will result in:
- Larger Environment Manager Personalization databases
- Larger Environment Manager Personalization archives
- Larger database backups
- Slower overnight archiving routines
- Many more files that need saving, restoring and managing
- Slower user logins
- Ivanti Community: Internet Explorer Cookies and History
Each browser stores settings in a different way, however the concepts behind this data remains the same. Various folder locations, database files, and registry settings are used to store browser settings and over time this data will accumulate.
When discussing this with customers it is often a consideration during the initial sizing conversation, as per the following slide from the recent Ivanti Interchange event in Madrid:
When the decision is made to not incorporate browser settings into Personalization, then this will result in:
- Continuous cookie acceptance/GDPR compliance prompts
- No browsing history
- No website personalization where cookies are used to store settings
- No single sign on or automatic website authentication
When browser cookies are not roamed between sessions, this prompt will appear every time a user visit the website.
Another example is using the Office 365 portal:
When cookies are not captured in Environment Manager personalization, a user will have to accept this prompt each time they visit the portal.
Possibly the easiest way to think about this is by thinking about the “Delete Browsing History” option in Internet Explorer:
Not roaming the browser settings is like clicking the “Delete” button at the end of each session. The same is true for other browsers too.
And what about Windows 10?
When we look at Windows 10, things get slightly more complicated when we consider the Microsoft browsers (IE and Edge). Mozilla Firefox and Google Chrome are no different here so can be managed in the same way as before.
With Windows 10, the webcache folder which contains the webcachev01.dat database stored in the Personalization database as part of the “IE11 Cookies and History (W10, WS2016)” Windows Settings Group, has changed. The webcache database stores data for cookies, browsing history and temporary internet files amongst other items for both Internet Explorer and Microsoft Edge. There is also some data related to internet enabled Universal Web Platform (UWP/Windows Store) apps in there too.
In addition to this, browser settings are stored in different ways on different versions of Windows 10. For example, since Windows 10 1709 Fall Creators edition cookies for Internet Explorer are no longer stored in the shell:cookies folder and are stored entirely inside the webcache database.
This means that it may not be possible to share these settings between Windows 10 and Server 2016 operating systems due to the changes in the way data is stored.
How does this impact me?
If you are a new User Workspace Manager (UWM) customer, then this is something you will need to think about and decide how you want to handle as part of the design.
If you are an existing UWM customer, then you may want to take a look at how things have already been configured. You can check to see whether users are storing large amounts of data by using the Personalization Analysis tool in the Personalization console:
You can also run some SQL scripts against your database to get some statistics about the size of the data, the number of files being stored and how much storage is being used – see here.
Another KPI that might be worth looking at is logon times. Over time, browser data will often cause a degradation of logon times, which is generally due to the amount of data that is being stored. Transferring this data over the network at each logon often results in degrading logon times which may no longer be lightning fast like when you originally implemented UWM.
Understanding how to break down and understand logon times is much too complicated to get into here, however, there is a separate blog on this topic here.
Hopefully the information above is useful for potential, new and current UWM customers. The goal was to explain some of the gotcha’s and pitfalls when managing browser settings when using Environment Manager. There isn’t a one size fits all solution here and what is required will often be dictated by the business.
Here at Avanite we are proud to be an Ivanti One partner and specialize in problems related to the roaming of web and browser data in Windows. See the Avanite website for more information and check out my recent blogs: Understanding the Impact on Logon Times and The Impact of Browser Generated Data on an Ivanti UWM Environment Manager Personalization Database.