The M-Files Community will be updated on Tuesday, April 2, 2024 at 10:00 AM EST / 2:00 PM GMT and the update is expected to last for several hours. The site will be unavailable during this time.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Problem accessing M-Files server through local admin too

Hi M-Files and community, 

We have recently tried approach that was recommended for us in this entry some time ago. We have installed Admin and configure it accordingly to connect to our M-Files server. 

My colleague, who is vault and and SysAdmin on M-Files, has tried to connect remotely. The connection seems to work and he can see all metadata, workflows etc.

But when he tries to upload changes through his local admin to Admin server, he has experienced following error:

Basically, when he tries to select the package and related Index.xml (please be aware that the whole package is locally on his PC), he is getting strange error related to security:

"For security reasons, you can not browse the disk contents of a remote M-File server". 

Actually, he tries to select the package which is located on his PC using local Admin tool which is connected to our M-Files server. It seems that selection reaches M-Files server instead of local C drive. He also tried to add a full path but it has not worked well.

Is using of Admin tool only limited to be used on M-Files server? Does it mean that all Admins would need to log on on remote server to upload and setup changes and could not use local installed Admins configured to connect to remote M-Files server?

Could someone clarify the usage of Admin tool and what is usual usage? It would be pity that we would need to connect remotely to M-Files server to upload configurations.

Thanks for your experiences.

Dejan

Parents
  • I haven't personally tried in a while but I believe it used to be the case that replication packages needed to be set up on the server; the "path" you provide has to be a path on the server, not a local path.

    It may be that one of the support engineers can reply and confirm.

Reply
  • I haven't personally tried in a while but I believe it used to be the case that replication packages needed to be set up on the server; the "path" you provide has to be a path on the server, not a local path.

    It may be that one of the support engineers can reply and confirm.

Children
  • Y/es, this is exactly how it goes. When you press "browse", you will be browsing your local computer, not the remote server. The whole configuration config must remain at the "local server machine" so you need to know the exact static paths to those files you are adding to the location paths. You cannot "browse" server machine from the other machine. 

    This also goes when you are adding ODBC connections. Even everything looks cool on your own computer, strings are fine and so on, it's still possible that the server itself does not have the required driver installed, even your own computer does. 

    This would basically lead to an error situation as well. That's why we recommend doing these major configuration stuff directly on the server, not at the remote workstation. 

  • Hi Timo, 

    Thanks for clarification and answer. 

    The idea was that people do not need always to connect remotely to specific server (some people are admins on vault but their account does not have remote access connections). This is why it would be great if those people would have local admin tool but connected to remote server which actually also works. 

    As the package is exported from other environment, I do not see why someone could not take the local package and upload it to remote server. It is strange because setup and configuration of AD groups, changing metadata can be done with local admin but deploying local package not. So it means some parts of Admin can be used and some not.

    This will be hard to explain for admins who are used to work with other document management products such as Sharepoint, Livelink etc. where they even have web access from their PCs. I think this you should consider changing this or at least thinking for web admin access for deployment of packages. 

    Best regards,

    Dejan

  • As a matter fact, I've filed an improvement idea about this already on August 2014. 

    Seems it slipped past the serious consideration back then. 

    I just dug that out from the system and updated it so that it will again show up at the product management reviews :) 

    For the reference, the improvement idea id is #62998 - "Web based configuration tool to replace MFAdmin"

    Lets see if it this time would catch some sparkles.. :)

  • :) thanks Timo, I appreciate it!