Virtually Jason

I was working with one of my ProfileUnity customers and they decided that they wanted to change the file server for their user profile repository.  This path gets used in a lot of different places of a configuration.  The easiest way to change it in the GUI is to just create a new configuration (using the wizard) and specify the new file server.  In this case, that wasn’t really an option as they had a very developed configuration with a lot of customized settings that we didn’t want to recreate.  Fortunately, there’s a nice easy work around to make such changes. From the main ProfileUnity page, just download your configuration.  Instead of saving it as an .ini (like you would when transferring it into your domain\netlogin\ProfileUnity folder, export it as a .json file.  This .json file is ultimately just a text file… which means that you can open it up in your text editor of choice and use “find and replace” to great effect. When doing this, bear in mind that the backslash has spe

I recently had the chance to do some testing with PernixData ’s vSphere solution and it was very educational.  It worked great, doing exactly what it was supposed to do… and it also got me thinking about the nature of storage caching. For just about ever, caching has been the technique that allows storage devices to provide the blazing performance that we all demand.  Monolithic SANs always have some amount of cache on their controllers.  What exactly does that cache do?  As the name implies, it caches data.  On those SANs, we would typically assign some amount of read cache and some amount of write cache (I’ve typically biased my vSphere storage devices heavily towards write cache, but opinions vary).  When a write request comes in, it is very quickly written to that cache and the acknowledgement is sent to the device that is performing the write.  The SAN’s job is then to destage the data from the cache onto the disks for long term storage, which only happens as fast as those di