This article assumes familiarity with FileUpdater admin and client functionality.  

Keeping track of what is published

FileUpdater is an effective tool to distribute files but keeping an overview of changes is left up to the administrator.
As a result it is not uncommon that organizations lose relevant information about what files are distributed with FileUpdater and whether or not it differs from the working copy. Especially if an administrator changes position and has not documented their workflow.
Depending on the rigor of procedures and documentation, number of admins etc. it can be difficult keeping track of changes between the working copy or Profile and what is already published and in production.

A misstep could potentially result in new templates being launched prematurely or in some cases previously added and desired changes being overwritten.

Establish a change process

Some organizations use a stringent governance model including change logs for when all files are changed added or deleted as well as when updates were pushed to different environments. Others simply keep a readme file with the most important notes and copy a backup of the files folder appended with the date each time a change is published.
We recommend choosing a process for managing FileUpdater that is fitting for the individual organization, being consistent with it and documenting at least to some degree the overall setup, including relevant locations (Profile and SOURCEURL) and agreed upon change process as well as some measure of version control.

How to check for differences

If it is not known it is possible to identify the difference in the Profile files from the publish files. One way is to retrieve the published files and compare them to the files in the Profile. This can be done by file hash or with version control software such as Git.

Another way is to publish the Profile to a new location and compare the two filelist.xml.

Retrieve published files and compare to those in Profile 

The most straight forward way is to access the files where they are hosted - at the SOURCEURL. With access to that location one can copy the files to another location and analyze the contents.

If doing this be very careful not to delete anything.

But if using the configuration "ENCRYPTED"="True", which we recommend doing, that is not an option as the files are all archived and encrypted.

Another way to check for differences regardless of the encryption configuration is to install the FileUpdater client with the installation parameters in question and compare the Cache that is downloaded with the files in the Profile folder.

To get the files that are published to a given repository e.g. in production

1. Ensure the solution in question (SDUpdater.msi) is installed - if more than one repository is managed with FileUpdater - make sure the correct one is installed with it's parameters in the registry. See https://support.omnidocs.com/hc/en-us/articles/360019388898-SOURCEURL-RepositoryURL for more on installation parameters.
2. Wait for the FileUpdater client to finish the update
3. Go to C:\ProgramData\SkabelonDesign\SDUP\Cache. 

The cache contains a copy of the latest published file set as it will be copied to the users' local folders as well as a copy of the filelist.xml from the SOURCEURL.

Zip files that are published will be extracted in place and the zip file deleted on users machines including the cache. This is especially practical if there is a large collection of files that rarely or never change.
For example there could be a zip file full of flag icons for user profiles containing 239 png files. In the Profile and on the SOURCEURL it is still an archive. But on users machines including the cache the zip file is extracted and then removed leaving only the files that were inside.

There is no Registry entries folder in the cache but the information of which registry entries are in the published package is available in the file C:\ProgramData\SkabelonDesign\SDUP\Cache\settings\filelist.xml along with all the files. The registry entries are at the end of the filelist.xml after the files.

Perform filelist.xml comparison

1. Copy the filelist.xml from the repository in question at [SOURCEURL]\settings\filelist.xml to a local folder
2. Navigate to the Profile which manages the files of this repository
3. Copy the profile.xml for a backup then change the SOURCEURL in profile.xml to another path, such as a local folder e.g. C:\ProgramData\FileUpdaterTest
4. Right click and publish to the new path (C:\ProgramData\FileUpdaterTest) - do not forget to delete this new profile.xml and rename the backup so it is named profile.xml. That way the Profile is unchanged and ready for use again.
5. Open the new C:\ProgramData\FileUpdaterTest\settings\filelist.xml with a text editor e.g. Notepad ++
6. Replace the new SourceBasePath <SourceBasePath>file:///C:/ProgramData/\FileUpdaterTest/files</SourceBasePath> with the SourceBasePath that is in the "real" repository
7. Compare the two filelist.xml files with a program such as WinMerge or DiffMerge

If the files are identical everything is up to date between the files and registry entries in the Profile and the (pusblished) repository

If assistance is needed do not hesitate to contact us via omnidocs.com/support.