Is FM a "published app" or do the users first log into the desktop and then launch FM from there?
Given that the administrators don't have a problem, that would point to the user's profiles on windows...
(unless the onOpen routine of your solution shortcuts for admins and runs the full gamut for non-admin)
Users log in to the RDP server. Then they open the shortcut. The shortcut is a small FM solution which simply opens a remote solution.
The delay mentioned, 2-3 min, is the amount of time between clicking on the shortcut solution, and displaying an FM window.
Have reverted back to FM12v4, and same solution opens FM within a second or two.
Have you done any development work or layout work in 13?
In this shortcut solution? No
Again, the delay occurs even when opening the FM application itself, 2-3 min before the window opens.
And if you open FileMaker directly no via your short cut are you getting the same delay?
If you open the solution as a user but with script debugger on can you pinpoint where the slowdown occurs?
Has the solution been moved recently so that there could now be faulty file references?
The delay takes place before the first window opens or the first script runs . Once the first window opens, the script runs immediately, and the login window for the target solution appears..
I do have remote access from my home Mac and laptop PC for dev purposes. There is no delay, either in opening the application, or in connecting to the target solution.
Have you tried to run this on a separate computer? Results?
This isnt a fix, but could help tell us if it is 100% a FM13 problem or soemthing else with the VM soltuion.
I'm assuming that there is more than one file in the solution?
Since it opens fine for you remotely but not when opened by the RDP users it takes a long time I wonder if file references are a factor. Can you post a screenshot of the file references?
Just to be clear: the delay is NOT in FM launching but after FM has already started and when you try to open the file right? If the delay is in launching FM, it could be plugins for instance.
No, delay is launching FM. No delay between first window open and login to target solution.
See thread above. Note, it does not happen to me, as an admin on the RDP VM. Only to regular users.
Shortcut solution, the actual FM file, resides in Public Desktop folder.
I don't think I was clear; I was trying to find out if the delay is in:
- launching the FileMaker application itself (not opening a FM file)
- or in the opening of the FM file itself
I may have found an issue that may be contributing to the delay on startup... Everytime a user starts up any FileMaker 13 application prior to opening files, FileMaker conducts a HTTPS "post" to a server at FMI. The information payload includes the license key and version number as well as the user local IP address. I discovered this by accident while running a port tracing utility on my PC. The transmission is copied below:
***** Filemaker Post at Startup (Our Lic key masked) ******
POST /public/product_stats HTTP/1.1
2 200 HTTPS www.filemaker.com/public/product_stats 0 text/html; charset=ISO-8859-1 filemaker pro advanced:6984
Depending on the configuration of your virtual desktop environment, this could create an issue. I can't tell for sure what the time-out setting is. I guess if FMI feels the need to gather statistics or verify license keys, I do not mind.... But I noticed the startup delay or pause myself everytime we open filemaker. I think FMI should have notified us that this was occurring. Maybe they did in the fine print somewhere, but I haven't seen it.