Just a quick drop and run post. While working with a particularly secure environment, many facets of ShareFile’s plugins would either not work, or certain features would not work.
Trying to find which Domain’s and URL’s were being used and called in order to categorise them was a royal pain in the ass inside of a secure virtual desktop, so here’s the list below if you’re facing the same task:
<yourdomain>.sharefile.com (or .eu)
secure.sf-api.com (and/or .eu)
if you want a sweeping statement, just whitelist sf-api.com and sf-api.eu.
Note, if you want full compatibility with all IE versions, also stick the domains in trusted sites.
* The external DNS name of your storage zone controller
two years ago at an E2EVC event, the concept behind ThinIO was born with just a mad scientist idea amongst peers.
If you are lucky enough to be attending E2EVC this weekend, David and I will be there presenting ThinIO and maybe, just maybe there will be an announcement. Our session is on Saturday at 15:30 so pop by, you won’t be disappointed.
Back on topic:
So here’s a really interesting blog post. Remote Desktop Services (XenApp / XenDesktop hosted shared) or whatever you like to call it. RDS really presents a fun caching platform for us, as it allows us to deal with a much higher IO volume and achieve deeper savings.
We’ve really tested the heck out of this platform for how we perform on Microsoft RDS, Horizon View RDS integration and Citrix XenSplitPersonality with Machine Creation Services.
The figures we are sharing today are based on the following configuration and load test:
Citrix XenDesktop 7.6
Windows Server 2012 r2
Citrix User Profile Manager.
16gb of Ram.
LoginVSI 4.1 medium workload 1 hour test.
VMFS 5 volume.
Diving straight in, lets start by looking at the volume of savings across three cache types.
In this industry when somebody says ‘boot storms!’ – most of us will respond with:
Boot storms are a well documented, boring problem and have many solutions available from vendors and hypervisors alike. Most solutions today rely on a ‘shared memory’ storage area to cache ‘on boot’, in theory caching only one startup or one pattern in order to then serve it back to the proceeding desktops to boot.
But why are boot storms an issue? While working on ThinIO we had the unique ability to really dive into the Windows boot process and analyse why boot storms cause the damage they do and in this post we thought we’d share our findings to better document the issue.
As we draw ever closer to ThinIO’s big day, I thought I’d put a blog post together talking about the RAM caching, statistics, facts and figures we’ve baked into version 1 to deliver some really kick ass performance improvements with even the smallest of allocations of cache per VM.
Test, test, review and tune. Rinse and repeat!
We’ve spent months load testing, tuning, fixing and retesting ThinIO. And for the first time we’re going to start talking about the dramatic results ThinIO can have on storage scalability and user perceived performance.
During our extensive testing cycles, we’ve covered:
• Horizon View
• Citrix XenDesktop
• Microsoft RDS
We’ve been seeing very similar, if not identical results when testing against pools on the following storage types too:
• XenServer SR
• Microsoft Clustered Shared Volumes