1 Reply Latest reply on Nov 24, 2010 3:21 AM by lordhellfire

    FM Pro with roaming profiles on Terminal Server



      FM Pro with roaming profiles on Terminal Server



      Does anyone have any experience running FM PRO (10) on terminal servers using roaming or mandatory profiles?


      I am trying to get the optimum login speed for a user by reducing the amount of stuff that has to load when a user logs in and fires up fm pro.

      As I'm running a terminal server farm consisting of several servers, each time a user logs into a new terminal server for the first time they have to go through all the 'enter username',' would you like to download the latest version' checks etc.


      I want to disable these by using a Windows  roaming profile or mandatory profile that has had these settings pre-selected for the user.


      I can't get it to work reliably, login speeds are seemingly random and sometimes FM Pro just crashes out entirely.


      I'm using FM Pro 10, Windows Server 2008 R2.


      If anyone has any suggestions or pointers I would appreciate it.




        • 1. Re: FM Pro with roaming profiles on Terminal Server

          You could upgrade your server farm to use clustering where all settings and data are transferred from server to server, but that is a whole different ballgame and brings with it a host of other issues, but bring more stability and load sharing to the setup.

          Depending on how your system is set up, the solution is different.

          Are the terminal servers individual servers with individual AD's or are they all authentication up against the same AD server?

          If they are authenticating up against the same AD, you can set up a group policy defining what programs can and cannot start up under the users. You have to define this in each AD, if each server has their own, but here you cannot avoid having to create the users individually on each AD.

          Running multiple Terminal Servers should preferably authenticate against the same AD for easiest user management.

          If each server has their own AD, you can set them up to run inside the same domain and replicate user settings between the servers. This should prevent the issue of users having to setup their settings for each server they log in to.

          Remember to play with these issues in a "sandbox" before you decide to implement any solutions. Messing with these settings/solutions be problematic for active users.

          By "sandbox" I'd recomment a duplicate setup of a part of the network inside a VMWare shell, where you can play all you want without disrupting the actual production environment.

          Good luck

          Peter F.