SalesLogix Windows Client and ComboFix
Posted By: Alex.Cottner on December 28th, 2011 in General, Saleslogix, SSS News
No Gravatar

Update: 1/18/2013 – Brad (author of the comment below) reports that he found a solution to this problem.

Yesterday we discovered a major conflict between the SalesLogix windows application and the Anti-Malware utility ComboFix. DO NOT USE ComboFix if you are a SalesLogix customer using the SalesLogix Windows Application (remote or LAN). SalesLogix customers using the Web applications only do not have to worry about this problem.

After ComboFix is ran on a computer with SalesLogix installed on it, SalesLogix is unable to process queue files. Because of this the queue files build up on the client machine and are never sent to the server to be processed for synchronization. This means that the changes the user is making appear to be going through properly (since they apply to the user’s database and no error messages ever come up), however these changes will never sync out to any other databases. We have tested and confirmed this with SalesLogix 7.5.2 on a Windows XP machine. I think it is safe to assume that this affects all versions of SalesLogix on all versions of Windows for now.

There is currently no known fix for this issue other than re-imaging machines. We have a support case opened with Sage to help us figure out what ComboFix may be breaking so we can create a resolution.

Update from Sage.

ComboFix alters the host operating system so that SLXSystem.exe can no longer process QUE\QTS files properly. The only known resolution for this issue is to reinstall the host operating system.


2 Responses to “SalesLogix Windows Client and ComboFix”

  1. BradNo Gravatar says:

    I have fixed this issue.

    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.

    • Alex.CottnerNo Gravatar says:

      I’m glad to see somebody finally got to the bottom of this problem. Good show, sir! Hopefully this information will make some other people’s lives easier.

Leave a Reply