Automatic update installation package folder and registry settings

Hi,

when automatically updating M-Files Client is there some way to change the default installation package folder? I think it's currently in "C:\Program Files\Common Files\Motive\M-Files Setup Packages", but I may be wrong.

The reason I would like to change the package location is because we are setting automatic updates for users via automatic update registry settings, but we encountered issues with network, because about 80 users started downloading large update installation packages at ones from the internet and the network can't handle it very well. My thought was to download the msi file once, put it into some shared folder and just set the installation package folder location to that shared folder for all users.

I know you can do automatic updates via GPO very similar to this using some XML and scripts, etc., but I was just trying to find the simplest solution to updates accross the whole company.

And my second question, which kind of follows up the previous one, is... Is there any list of registry keys/settings for M-Files? I sometimes find registry keys in regedit that are related to M-Files, but I can't find any documentation for them on the internet. That one I would really appreciate, because sometimes I spend a lot of time searching through the forums, support website and the public cloud only to find out that the key or setting I'm searching for probably doesn't even exist.

Thank you for any feedback.

Regards, Dominik

Parents
  • Hi there, 

    I would suggest you send a support request to the Customer support team of M-Files regarding the settings. Alternatively, I let system specialists like Joonas or Craig answer the first question, but I can answer right away for the second question. 

    As the registry keys are needed to change the default behavior of the software, we provide them after consideration upon request. There is no such list available for a good reason. In the worst case, an unaware IT guy could set such keys that would cause serious harm to the system by the set values. 

  • Hi, thank you for the quick reply. I understand.

    I think we will try to update the clients using the custom installation method mentioned in documentation provided here:
    https://m-files.my.site.com/s/article/mfiles-ka-166483

    Or by following this support article, which would require more manual work:
    https://m-files.my.site.com/s/article/Balancing-the-network-load-caused-by-M-Files-automatic-updates

    Either way, we will probably figure it out somehow, I was just trying to find some alternative ways to update maybe more easily.

    And if I may give some feedback on the registry key list:

    Then wouldn't it be possible to make a list of safe-to-modify registry keys? I understand that in essence, there is no real "safe-to-modify" registry key, but at the same time some settings require a change of registry keys, such as changing/removing the logout timer until version 23.3 (AutomaticLogoutTimeoutInMinutes), or changing the maximum amount of times properties can nest (Property1.Property2.etc...). Because of that, I think that a list registry keys that are officially the only way to change some functionality would be useful.

    Of course, unaware system administrators can always cause some harm to a system, but I think there is a line between responsibility of a system provider and the responsibility of the company hiring and training the IT guy who causes the harm.

    Just wanted to share my thoughts. Thanks again.

Reply
  • Hi, thank you for the quick reply. I understand.

    I think we will try to update the clients using the custom installation method mentioned in documentation provided here:
    https://m-files.my.site.com/s/article/mfiles-ka-166483

    Or by following this support article, which would require more manual work:
    https://m-files.my.site.com/s/article/Balancing-the-network-load-caused-by-M-Files-automatic-updates

    Either way, we will probably figure it out somehow, I was just trying to find some alternative ways to update maybe more easily.

    And if I may give some feedback on the registry key list:

    Then wouldn't it be possible to make a list of safe-to-modify registry keys? I understand that in essence, there is no real "safe-to-modify" registry key, but at the same time some settings require a change of registry keys, such as changing/removing the logout timer until version 23.3 (AutomaticLogoutTimeoutInMinutes), or changing the maximum amount of times properties can nest (Property1.Property2.etc...). Because of that, I think that a list registry keys that are officially the only way to change some functionality would be useful.

    Of course, unaware system administrators can always cause some harm to a system, but I think there is a line between responsibility of a system provider and the responsibility of the company hiring and training the IT guy who causes the harm.

    Just wanted to share my thoughts. Thanks again.

Children
  • I understand your viewpoint, and I agree with the sentiment of it.

    Just a quick note to say that we've been trying to move away from registry keys over the last couple of years; many of those that were available - where appropriate - have now been migrated to Advanced Vault Settings.  This should make those values much more accessible than they were before.

    I know that some of these registry settings are perhaps not appropriate for AVS, but in general terms that's the route we're trying to take.

  • I see, I was thinking this was the case when I noticed today that you put the AutomaticLogoutTimeoutInMinutes key into AVS in the 23.3. update, which I think is a great change overall, together with moving away from registry keys.

    Anyway, thanks a lot for the information, wish you a nice day!