Windows Runtime Solution Deployment - folders, permissions, Win7

[Jonathan9]

I have a runtime (v11) which is distributed to a several hundred users, and as with all users, they have different systems, some are just home/personal laptops, some are corporate secured down laptops, some standalone, some network.

I always create a custom installer, which copies the runtime files to the specified location, adds start menu/desktop shortcuts etc.

The runtime has several files with data, but as with most runtimes the data is held in the same area as the runtime files as it seems the best option, the system has a backup routines, which also places backup files in the file location determined by FileMaker scripts (as we didn't want to use plug-ins to give access to user defined folder areas).

With XP and before I had always installed into Program Files and this was rarely an issue as 99% of users had read write access. However now a large proportion of users are running Windows 7 (some Vista), the issue of protected folders and admin rights is far more complex and causing issues.

If the user doesn't have full admin rights (or over-rides the UAC), and most of the users for this system aren't technical and don't understand the issues, they cannot add or edit data in a runtime system installed into Program Files at all.

Program Files is a protected folder and Microsoft encourage developers to install user data to: AppData, LocalAppData, ProgramData. However as the user will need to access the installed folder for upgrades and backups, I don't feel these are ideal locations, as they are too obscure. It is considered bad practice to ask the users to alter security settings just to run a program which doesn't fit into MS guidelines.

Documents / My Documents is out as if the PC is on a network system, Docs is a network folder, and performance takes a hit.

Have considered creating and supplied a unique USB key for the system, but with users on older USB 1.1 the performance is useless.

How are others approaching this? I'd be interested to hear your thoughts...

[Cabinetman]

BUMP !!

I'm not to far from deployment testing and am wondering also......

i haven't gotten into the 'installer problems yet and am dreading it !

[egurewitz]

I have my users install to the root c: drive. It works fine and the solutions folder is easy to find for doing external backups, etc,

[Vaughan]

I have my users install to the root c: drive. It works fine and the solutions folder is easy to find for doing external backups, etc,

This will NOT work in many corporate environments, or where the user is running with less-than-administrator privileges.

[Vaughan]

I had to re-engineer a solution a couple of years ago because it exported temporary csv files to the program folder then re-imported them (lots of 6-think to simulate GTRR). It worked for the developer who always ran as administrator but failed for users who ran with less privileges and for whom the program folder was read-only. This was on Mac. Same problem for PCs.

Learn which folders the users always have write access to -- the temporary folder and the documents folder. Write to any others at your peril.

[asavasamuel]

Jonathan9

 

 

Here is a database compatible with Windows Runtime:
https://www.kellermansoftware.com/p-49-ninja-winrt-database.aspx

[rigman]

WOW. I can't believe FM has not addressed this as of version 12v4... It's must be a known issue for years now.

 

Every decent windows application that needs to write data in windows 7 or 8 will write to the %appdata% directory.

 

Under the new security policies Microsoft explicitly protects the program files directory, it should not host any user modifiable files.

 

The database files should be installed in appdata, while the runtime should be in the program files folder. Problem is how does the runtime EXE know where the datafiles are now... big bummer for those needing to deploy commercial apps (runtimes).

 

Having an installer run and then having to give your customer instructions on how to explicitly provide admin rights to the app so that it runs right is just ridiculous. Has anyone found a work-around this issue? (while keeping the runtime in program files).

[Lee Smith]

11 post and yet you haven’t disclosed your current information. Please update your profile to reflect your current FileMaker Version, OS, and Platform. Here is a quick link for you MY PROFILE.

[AGG]

We have solved this problem using the InstallMate Builder by Tarma Software. Tarma has a utility called GiveAccess, which may be invoked during installation and transparently (i.e., no user intervention required) changes the permissions of selected files and folders.  If you make your runtime data files world writeable it solves all of the permissions headaches mentioned above and will permit you to install the FM runtime in the Program Files directory.  We distribute an FM runtime application to many hundreds of users and have had no problems installing and running it on Windows 7 or 8.  Hope this helps.

[rigman]

Well I'm pretty sure I had filled that profile in the beginning but it's been years since I've been in this forum.

 

Thank you very much for the tip on the GiveAccess software. I had tried changing registry without success. Of course if the user does this manually then this is no trouble but my solutions cater to the non-power users so this has to be resolved from the install.

 

I will give it a try but I see they have the 32bit and 64 bit versions so I'm wondering if I should use the 32 bit version when I am installing the 32bit runtime files in a 64 bit Windows O.S. system... have you had experience with these situations?

 

It would be great not having to deal with detecting the bit versions of the O.S. to launch the correct version of GiveAccess.

[Lee Smith]

Well I'm pretty sure I had filled that profile in the beginning but it's been years since I've been in this forum.

 

The only way it would have changed is that you, or a Moderator, had modified it. Although a Moderator has the ability to edit your profile, there would be no reason to do so, nor do we have the time.

 

In any event, since it has been years, it was most likely out of date and needs to be updated anyway.

[AGG]

Well I'm pretty sure I had filled that profile in the beginning but it's been years since I've been in this forum.

 

Thank you very much for the tip on the GiveAccess software. I had tried changing registry without success. Of course if the user does this manually then this is no trouble but my solutions cater to the non-power users so this has to be resolved from the install.

 

I will give it a try but I see they have the 32bit and 64 bit versions so I'm wondering if I should use the 32 bit version when I am installing the 32bit runtime files in a 64 bit Windows O.S. system... have you had experience with these situations?

 

It would be great not having to deal with detecting the bit versions of the O.S. to launch the correct version of GiveAccess.

 

What's important is your development machine.  For example, if you're installing Installmate on a 32-bit computer then you need the 32-bit version of the software.  I am running a 64-bit development system so I use the 64-bit version.  Installmate will automatically install your software in the appropriate Program Files directory on the user's platform depending upon whether its a 32 or 64-bit program that you've created.  You don't need to detect anything.  This has never been a problem for us and since our software is consumer oriented (non-power users) I am sure that our end users run both kinds of systems.  BTW, we've never had to change registry settings to get our runtime to install properly.

 

BTW,  I have no interest -- financial or otherwise -- in Tarma software and know none of the developers.