Think of the SYNC

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

With the introduction of Windows Settings Groups to Personalization the support team see a number of customers raising support incidents where Personalization data fails to sync back to the database and users are reporting settings not saving.

The typical support call raised is when users are reporting that most Personalized settings are syncing correctly but any changes made to do not persist between sessions.

There are two main reasons why this happens.

Reason 1

The size of the user’s profile that is being uploaded to the database. By default, the maximum allowed size is 30000000 bytes (30mb) of data for the user’s profile data, and this is a limit set with IIS. Information on this limit is covered in the following knowledge article:

http://www.appsense.com/kb/150622256549878 (login required)

Reason 2

Similar to the above, but it’s not the size that’s the issue but the number of individual files that are contained within the user’s profile that need to be synced. By default, the maximum number of files that can be allowed in a request is 1000. Information on this limit is covered in the following knowledge article:

http://www.appsense.com/kb/150622256549878 (login required)

So before we look to increase the limits its important to first understand which limit is being hit and why. Also whether increasing the limit is the best solution.

The best way to troubleshoot this issue and identify why Personalized settings are not making it back to the server is to turn on Environment Manager debug logging to capture at logoff. The AppSense Support Toolkit has a logging tab and is the best option to enable logging. The Support Toolkit can be downloaded from the following link:

http://www.appsense.com/kb/150713094314677

Once logging is enabled you can then ask the user to login, make the changes that are not persisting and then logoff. Once this is done you can stop logging and an ETL file will then be created in the log directory you have specified in the Support Toolkit.

The first issue we will look at is the IIS file size limit by reviewing the ETL log file. The ETL log file can be viewed in the tool EMMon that is shipped with Environment Manager and is installed by running the Environment Manager tools MSI from the downloaded media in the Software\Products folder.

Once installed, run the tool and load in the ETL file generated. Select the option to ‘Analyze user activity’, this will then bring up the data in a grid view that we can filter as below.

From this we can apply the filters. We know this is a Personalization issue so we can narrow the filter down to Personalization and as we are looking for a failure we can select the failed events only.

As you can see from below this simple filter brings the log down to one line

From this one screenshot we can see that the Sync up of windows Personalization failed, the error code is a HTTP 404 error

[SyncManager::HttpSync] ERROR - Sync HTTP error [404], bailing out of sync.

As this is a HTTP sync error its useful to review the IIS logs to see if we can understand the 404 error further as the IIS logs will expand on the 404 error. A useful tool for reviewing IIS logs is Log Parser Studio from Microsoft:

https://learn.microsoft.com/en-us/powershell/

It’s very useful to analyse large IIS logs and to summarize the URL requests. From the IIS logs we will see that the sub code is 404.13 which represents content to large and is seen when an attempt is made to upload a file larger than a pre-determined limit.

So it’s clear that we have a user that is trying to sync a large file, and this confirms the KB:

http://www.appsense.com/kb/150622256549878 (login required)

We now have two options, we can increase the 30mb limit until the sync completes or we can review the log file further to understand if this is simply a number of smaller files adding up to the limit which may justify the increase to the limit, or has the user added a file that is simply to large causing the issue.

To do this in EMMon, we can use the filter editor to add a filter on the Raw Log Line to contain the word “size”.

The filter editor is found by right clicking on a column header and selecting filter editor.

In this case we can see that the user has a DOCX file that is 93153856 bytes (93mb). It also shows which Windows Settings Group the file is being sync to.

[EMClientProfileSync::AddAppDataFile] Adding compressed file \\?\C:\appsensevirtual\S-1-5-21-1518854212-1664430644-2001430820-1104\{C45B3F00-B169-4E20-9E3B-F0D228B47CBF}\Dsktp\Registry\Explorer Settings\CSIDL_APPDATA\Microsoft\Windows\Libraries\OfficeScanner.docx, size 93153856

Armed with this information we can speak to the user and ask why they have this file in this location and if it can be moved to a location of the profile not managed by Personalization such as ‘Documents’.

This is why it’s important to understand your Windows Settings Groups and what is being synced. Do we want users to have a Profile bigger than 30mb? The bigger the size of the profile, will result in impacting the user’s logon / logoff times.

We may need to increase the limit in some environments as the data size could be a build-up of a number of files needed, but it’s always important to review the data to ensure the resolution is correct for your environment.

Hopefully the above explains the KB article further and provides some helpful information on using EMMon to identify an issue.

The next part of the Blog will focus on the secondary issue we also see reported which is the number of files to be synced. Microsoft Security update KB2656356 / MS11-100 (released in December 2011) addresses a vulnerability in ASP.net which could allow a denial of service by a malicious user. This update enforces the maximum number of form keys, files and JSON payload members allowed in an ASP.NET request to 1000.

Again we can follow the same troubleshooting steps and capture a logoff within EM Debug logs and review the ETL log file within EMMon, the same filter can be used as above.

From the above screenshot we can see the failure of the Windows Personalization sync, the error code this time is

[SyncManager::HttpSync] ERROR - Sync HTTP error [500], bailing out of sync.

From this a search of above error on the Support Portal would point you to KB:

http://www.appsense.com/kb/150622256549878 (login required)

Once we understand the issue is due to the above KB, we can then review the user’s data to identify the Windows Settings Group causing the issue.

[EMClientProfileSync::GenerateUpdates] New file list contains 7611 items

In this case we can see that the Windows Setting Group is:

IE10+ Cookies and History (W7 WS2K8 R2)

And the location with over 2000 files to sync in

CSIDL_APPDATA\Microsoft\Windows\Cookies\

This can be seen by the following extract

The Environment Manager agent will compress each file and crate a .gz file and number this sequentially. Once you identify that the .gz file has passed 1000 this will cause the error.

This issue can be seen a lot when cookies are being captured as part of a Windows Settings Group, as by the nature of cookies these can build up and a user can have 700 - 800 cookies fairly quickly, if we then combine other applications we can hit the 1000 limit soon.

Our Professional Services team set the limit to 2000 as this covers most scenarios, but as with the first issue we need to understand if this is the best approach.

In summary both the above issues demonstrate how simply it is to set up Windows Settings Groups, but not thinking about what that group could potentially sync can lead to users reporting data failing to persist and even slow logon / logoff.

It always a good idea to ensure that the correct file type exclusions are added and that the path includes are relevant and needed to ensure you are only capturing the required data for the user.

I hope the above provides some tips on troubleshooting a sync issue. Don’t forget the Support Team is here to help if you get stuck with the logs, simply log an incident via the Support Portal, documenting any errors you have found and provide the logs, this will help the team progress your incident.