AppSense Personalization Archiving
One of our clients had errors with the automatic archiving job. To solve this I had to dive into all the settings, but could not find documentation of it in one place. So I wrote an article to share with you.
Archiving enables application and desktop settings to be rolled back to previous states in event of profile inconsistencies. The great thing about the AppSense way of working is that, in contrast to the standard Windows profile, EM Personalization is split into small pieces, allowing you to restore only the erroneous settings.
When you go into the Personalization Analysis, you will see that the last tab is called Archives. Here you have an overview of all the applications and application groups with their archives. As you can see in the screenshot below, Archives are only created in case something changed. This makes it easier to rollback to the correct version.
If you want to create a backup of a profile before doing tests with a new application, you’ll have to be here. With a right click on the application, you can create a manual archive. By default 5 archives are kept, but the dialog box for that manual archive provides you with an option to protect the archive, to keep the archive until you manually delete it.
AppSense Personalization Background Service
It is the service called “AppSense Personalization Background Service” that handles all tasks related to archives. The AppSense Personalization Background Service runs on the Personalization server. The archiving job runs at the time zone of the SQL server, not the Personalization Server machine. As you can see in the AppSense Personalization Server Configuration, the service is configured with an account name. This account needs to have sufficient access to the database to be able to run the scripts that generate new archives. (By default it will have ProfileServerService rights)
The AppSense Personalization Background Service creates the archives daily at 1:00 am. If you want to alter this timing, you have to go to the global settings of Personalization and change the value of DailyArchiveTime. If you want to alter the number of archives that are stored, you have to look for the setting NumberOfArchivesToKeep, which has a default of 5 versions.
To troubleshoot the Archiving service, it is best to filter the event viewer for events from source “AppSense Personalization Background Service”. Here you can see when the archiving starts and stops and what happens in between in following steps:
1) Check which archives where accessed since the previous job
2) Copy the profiles to archive into the table dbo.ApplicationDataArchive
3) Purge archives, according to the setting NumberOfArchivesToKeep
4) Remove data older then the setting MonthsOfUsageDataToKeep
5) Some other cleanup tasks according to the settings InactiveProfileExpiryMonths and InactiveUserExpiryMonths, but these settings are by default set to 0, which means that nothing will be removed.
6) And if all goes well, the last event is this:
On the Microsoft SQL Server
When I configure the backup of the SQL server, I always make sure the backup starts later then the finishing time of the archiving, so all archive data is also backed up.
The archives are stored in two tables (dbo.ApplicationDataArchive & dbo.ApplicationProfileArchive). On the Microsoft SQL server the two tables are kept in a separate file, enabling you to store your archive data on cheaper disks.
In case you are working on an environment where the Personalization database is being replicated to multiple sites, it is good to know that by default the archive data is only kept on the master server. This avoids replication of high amounts of data and makes it obvious to the admin on which server he will have to initiate a restore. When you do that restore on the master server, you’ll also have to initiate the replication to ensure the user has the correct data before he starts the application. You can initiate this in the console or on the SQL Server.
In the global settings you can see if your Personalization Server is part of a replication set (master/slave) or standalone (none) in the setting ReplicationType. This value is set by the archiving script and is not recommended to be changed by the user.