The AppSenseVirtual folder is used by Personalization Server to write file and Registry changes locally, before committing them to the Personalization Server database as required. The time of commitment will depend on when the application exits, whether it is part of an application group, and whether Offline Mode or Offline Resiliency is in action. This folder normally sits at %systemdrive%\AppSenseVirtual, and for most cases it will function quite happily in the default location. However, there may be instances – and I am thinking that these instances will be limited, it’s not a standard enhancement – where performance could be increased by moving the folder to another drive.
Disclaimers
AppSense will probably spit feathers when they see I’ve done a post on this, because they will be concerned about possible screw-ups, so let’s make their concerns unfounded, by taking note. You should NOT deploy this unless your monitoring indicates that you may see some benefit from this, or that problems are occurring because of the default location (for instance, I have seen instances of over-provisioning in this area in PVS environments). If you do decide to go for it, I would recommend standing up a separate database to test first (not just a test Deployment Group, Personalization Group or Personalization Server – a completely separate test database). If you do it on a production database, make ABSOLUTELY SURE that you have a functional backup of your database before proceeding. I am told that this method is supported, but if you make the changes without due diligence then I am going to assume neither AppSense support nor myself are going to help you out of the hole you’ve idiotically dug yourself into without significant reimbursement. As always – test thoroughly before starting down this road and make sure you follow backup and change control processes. You have been warned.
Well, now that’s all out of the way we can crack on 🙂
Changing the folder location
The image below shows the folder in its default location on the system drive. The folder is hidden, so you will have to enable the correct options to see it.
Strangely – and this is the reason for the vehemence of all the preceding disclaimers – the location of this AppSenseVirtual folder is controlled by an entry in the database, rather than anything in the consoles itself.
This raises another important point. Effectively, the location of the folder is set on a per-database basis. If you want one set of users to have it in one location and one set of users to have it in another, then on a base level you’re talking two different Personalization databases to achieve this.
I did think you may be able to get around this by using a system environment variable, but SQL won’t recognize a Windows environment variable – either server or client side – as far as I am aware. You’d probably have to do some fancy jiggery-pokery with stored procedures to effect this, and as AppSense would doubtless not support that sort of configuration, we can forget about customizing it. So if you want to move the AppSenseVirtual folder, it is a setting hard-coded for all users of that particular Personalization database. (Update – as pointed out by Shaun in the Comments, you can use a SYSTEM variable for this, so your options for multiple users are probably better than I previously intimated)
The table is the Global table, and the Property is RootFolder. You will need to log on to the SQL instance that your Personalization Server database is running in, and open up SQL Management Studio (or your tool of choice) – not forgetting to Run As Admin
Expand the Databases node under your instance, and expand the Personalization Server database (obviously the name may vary). Then expand the Tables section in the database.
Now, right-click the Global table (dbo.Global) and choose the Edit Top 200 Rows function
You will see data like this. The property we are interested in is highlighted
Now, we will have to be very careful about the value we put in here, because if it doesn’t exist on the endpoint, Personalization will simply fail to work at all. PersInfo will show an error of “configuration not found” or similar. So make sure that the area you are pointing it to exists!
We are going to move it to a persistent drive, which in this particular case is located on Z:
Once you’ve changed the value, clicking on a different cell will commit the change straight away, so make sure you’ve done it correctly.
Verification
Now, we will log on as a test user after we have made the change. You don’t need to create the folder in the redirected location (as long as the actual parent folder or drive exists), it will be created for you. The image below shows us the redirected location.
Running PersInfo shows us everything synchronizing as normal
so it appears that the change we made has been successful!
Reversing the process
The reversal process is simple – change the RootFolder database property back to %AppSenseProfileDirRoot%\AppSenseVirtual, and then log users back out and back in again. You will need to delete the new directory created (which in this example would have been Z:\AppSenseVirtual) to completely clean up after yourself.
Summary
Be very careful changing this – never lose sight of the fact that it is on a database level. As hinted at by the table name that you access, this is a global change and will affect all users of AppSense, so if you redirect the folder location to Z: and your laptop users have an X: drive instead, then you’re killing Personalization for that entire subset of users. Completely.
But if you do find that there is a performance gain or configuration advantage to be had from altering this for your environment, this is the way to do it. Hopefully this should help anyone who ever has the need to do it.
Share
