The Cookie Carnage

< Terug naar blog overzicht

The basics

Today a discussion around cookies and no I do not mean the cookie you can eat, but the HTTP cookies from the browser(s). Probably the most known, unknown feature of the browsers, if you’re a technical guy and don’t care about building websites.

Cookies have been around us since the ’94 and enhances the website or web-browsing experience, is what they say I honestly did not look into the files. The only thing I knew, we need to roam them if we want to make the user experience consistent. In the old days this was easy to do, by just moving the cookies files around from profile to profile. When a Workspace Management Tool was in place this was a lot easier and you just stuck to the basics and roamed the cookies folder.

But then the trouble began!

The number of cookies begin to increase so instead of a few cookies, the amount has grown to a significant number of cookies, that downgraded the logon experience for the user, because copying a large amount small files was never a good idea, while in session, but doing is during logon was even a worse idea. So as a good IT-consultant we needed to come up with a good idea to overcome this little problem.

The “Solution”?

During my consultancy engagements and pre-sales period I came across a lot of these solution that pretty much worked for quite a long time until disaster struck and Microsoft started to use small databases everywhere in the windows operating system starting from Internet Explorer 10+ . But about that a little later.

First the many solutions I introduced myself and seen in the field.

When using a virtualised environment, like a VDI or SBC, we need to do something for the user to create a consistent experience, so the builtin Microsoft solution is using roaming profiles. I’m not going to explain what a profile is or how it can be managed, there are a lot of articles about that on the internet, but the only thing I want to point out is. When using a roaming profile, a folder with the registry hive and the AppData folder is kept for the user on a central fileserver store.

During a logon session this profile gets loaded and at the end of the session when a user is logging off the profile is written back to the fileserver.

Folder Redirection

The big issue here is that cookies are kept appdata\local. This part of the profile is not roaming so from a user perspective the cookies are only kept on the local machine and the user will lose the consistent user experience, if we talk about browsing. So Microsoft has solved this by making cookies a special folder which you could redirect to a fileserver.

Problem solved you would think….

Well not really, it’s not recommended to redirect a folder with very small files to a fileserver. It’s works perfectly in the beginning, but over time the number increases and the fileserver gets busier and busier. The worst bit here is that internet Explorer for EVERY time the user types an URL into the browser the cookies folder is queried, with a large number of calls to the fileserver. Not really ideal. With the introduction with the latest and greatest browsers like IE 10+ or Edge redirecting the cookies folder and the WebCache databases for the users the problem became worst. By redirecting the webcache database I’ve seen a lot of corruptions of this database and we saw an increase in the number of support desk calls.

Essentially this leaves us with one option, roam the cookies somehow with the users and reduce the amount of cookies to roam.

Delete Cookies older than X Days

Before the introduction of IE10+, we could run a vbscript or powershell script to keep the number of cookies to a acceptable level. The script looks at the date of the file and deletes everything older then x number of days. This worked well until Microsoft decided to change the way cookies are called into the browser. With the introduction of Internet Explorer 10 a webcache ESE database was introduced with all the references pointers to the necessary cookies. The thought behind this is that an indexed database with cookies references is much quicker than a browser which needs to search a folder for the correct cookie. But the webcache is a lot more, it’s used for history, cookies, DOM Store objects, Windows Store Apps, etc.

Good thinking Microsoft, or not. Well on one hand yes, but if we look from a IT management perspective, roaming just became a lot harder.

We tried the script and just deleted the cookies older then x days. But then the browser became slower and slower and responded not as good as it supposed to do. By doing some research we found out the browser was digging into the database searching for cookies which were deleted and overtime searching deadlink references consumes so much time that the user experience is degrading. Deleting only the cookie files does not delete the references and leaves lots of orphaned records in the webcache.

So, we found out logically that there is strong relationship between the WebCache database and the cookie files. With the release of IE10+ deleting cookies was not a good solution. We wanted to give the user a consistent experience and we are not allowed to delete any cookie. What can we do to avoid this?

Copy it all

When we focus on the problem copying the cookies files from A to B, the copy action for the small files consumes the most time. This can be simulated by just creating a folder with a 10000 small 1kb files and copying it to a network location. This takes a lot of time…

Zipping it up

A solution might be zipping up the whole lot, but zipping itself cost CPU and Disk I/O. Searching for a solution we tried the zipping functionality built into Windows itself, this replaced the time it consumes for copying with the time it needed to zip it up. Net result is little progress. Even with the no compression option it still consumes time to execute it. Multiple customers also had 7-zip installed as the main compression tool and with the no compression option this was quicker, the issue here being we need an additional piece of software to make it work and you’re not managing the data you just roam shit out and shit in.

VHD Containerization

Another option was to redirect the cookies folder to a local VHD file. This way every cookie is immediately placed in a container (VHD) and accessed from here in the session. At logoff we detach the VHD and re-attach on the next logon. This works perfectly, except that most enterprises run with protected mode enabled and therefor it creates a low folder in the cookies folder. This folder is protected by Windows and cannot be changed. So the solution still does not work and again you’re not managing the data you just roam shit out and shit in.

FSLogix

FSLogix uses a (Mini) Filter Driver mechanism to allow the VHD containerization approach discussed in the previous section, and as such it doesn’t suffer from the Low folder limitation. This works with protected mode enabled but the same concept of shit out and shit in applies.

No roaming

Some customers I have worked with have also made the decision to no longer roam the webcache and cookies. The impact on the logon and the user experience of roaming this data caused too many issues so the decision was made to simply not do it any longer. It’s a solution but it provides users with a bad browsing experience with the cookies being needed to provide the consistency they demand. Unhappy users but a happy admin .

Workarounds sickness

We need a solution that does not just work around the problem, we need a solution that truly manage the cookies on our systems. Not only do we need to control this carnage, but cookies are not so harmless as we think. This is why Avanite has created a solution for the cookies problem… go have a look here

Pictures
Gerko van Veen(Architect)

Meer nieuws

Meer weten?

Laat uw gegevens achter en wij zullen zo snel mogelijk contact met u opnemen om uw vragen te beantwoorden.



Ik geef toestemming om mijn gegevens te verwerken op de manier zoals omschreven in de privacy verklaringIk geef toestemming om mijn gegevens te verwerken op de manier zoals omschreven in de privacy verklaring