Solution for Combofix breaking SalesLogix

The problem: When using Combofix on a system that has SalesLogix installed, it will prevent SLXSystem.exe from reading the QUEUEFiles directory(the directory that changes get put into so that they are put in the sync folder for remote databases) and as a result, remote user's databases will no longer receive updates from anyone entering anything into the SalesLogix database from that system HOWEVER local database users will see the changes. (Remember, just because your local users can see the changes does not mean your remote users can and your QUEUEFiles directory will have hundreds if not thousands of changes that have not been sent to your remote users)

When running process monitor on a working system, you can see that the SLXSystem.exe will receive a result of "SUCCESS" from the class "File System" with a list of files that match the filter *.qts

When it fails after running combofix, it will receive a response of "NO SUCH FILE" from the class "File System" meaning that the file system cannot locate any files ending in .qts

Why is that? Well, the files really end in more than just *.qts, they have the _servername_ as well.

The process to fix this is really simple in the long run. On my test system, I took a working registry, ran combofix, and compared all changes and it really boiled down to 3 small registry changes from the hundreds that have changed.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem]
"Win95TruncatedExtensions"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\FileSystem]
"Win95TruncatedExtensions"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"Win95TruncatedExtensions"=dword:00000001

Combofix changes the Win95TruncatedExtensions to 0. Because this happens, the file system sends a response to SLXsystem.exe a "NO SUCH FILE" because the file extension is interpreted as *.qt_ because of the length of the file extension. When changing this to 1 in each of the keys above, it will get a successful response. However, there are a few steps to get the old changes to purge.

So, to fix this, do as follows

1. Apply the registry changes listed above.
2. Move the qts files out of the C:\Documents and Settings\All Users\Application Data\SalesLogix\Sync\QUEUEFiles folder to a temporary directory.
3. Reboot the computer.
4. Open SLX and put in a test change.
5. Look in the C:\Documents and Settings\All Users\Application Data\SalesLogix\Sync\QUEUEFiles and verify the changes are now leaving.
6. wait 2 minutes for the SLXsystem.exe to cycle with the QUEUEFiles directory empty.
7. Move all your QTS files from your temporary directory to C:\Documents and Settings\All Users\Application Data\SalesLogix\Sync\QUEUEFiles

The changes should then start to purge from the system.

In my journey of trying to get this fixed, I ended up cutting all new remote databases back on 12/7/2012. Because of this, any system that had this problem, I deleted all of the QTS files on each of the effected systems prior to that date. If you have also made new remote databases in the process of trying to fix your issue, you may want to delete these files. I am not sure what the side effect would be of having these old QTS files apply to a remote database that already has those changes.

As you already know, there is a very specific thread that relates to this however I cannot post the solution to the issue since I did not create the thread. So here is the answer to anyone that has already ran combofix and has saleslogix.

 

True! Except I had this problem up to a few days ago and unknowingly had it for over a year on one of our PCs. Hopefully someone will come along and find the solution to the problem here since their "Sage"'s only solution was to re-image the machine ;-)