Hi!

We have a large access application (>100MB mdb with forms and reports,
some mde libraries, some additional files) that we want to deploy to
user's computers (data is stored in an SQL Server DB).

Back in the old days of Windows XP, life was "easy": You created an
installer that installed your application to C:\Program
Files\Whatever. Since every user (usually) had local administrative
access, it did not matter that the contents of the mdb were modified
during normal operation (temporary local tables being modified,
temporary local querys being created, tables being de-/attached,
report settings being changed etc.).

Now, in the days of Vista and Windows 7, users don't have write access
to C:\Program Files, which is a good thing in general, but it breaks
"classical" system-wide-installed mdb-based applications. Of course,
there are a few obvious ways to overcome this problem, e.g.:

(a) Give all users write access to C:\Program Files\Whatever.

(b) Install the application to every user's home directory
(C:\Users\username\AppData\...).

Clearly, (a) is ugly from a security point-of-view and (b) is ugly
from a maintainance point-of-view (think about updates etc.).

Since I'm surely not the only one having this problem, I'd like to ask
for opinions on this issue. Maybe there's a third way or even a
well-established "best practices" guide for deploying mdb-based
applications in environments where users are not local admins?

Greetings and TIA,
Heinrich

I don't get too much into this myself, but the 'best practice' seems to be to
put the app into the "Users\username\AppData\" folder, as it's the only one
we can always be sure of the user having full read/write permissions (trying
to give the user permissions to Program Files is probably not a good idea...
there's a reason its blocked).

As far as incorporating this into updates, you can use environment variables
in your install procedure to come up with this location:

"C:\Users\%USERNAME%\AppData\etc"

this %variable% format can be used inside a batch, or you can get the same
result in VBA with the Environ() function, thought it is generally
recommended to use the API defined for this purpose. Go to mvps.org/access
and seach the APIs section for Get Special Folder

AFIAK, this is the only way to make sure everything works smoothly with Vista.

hth
--
Jack Leach
www.tristatemachine.com

"I haven't failed, I've found ten thousand ways that don't work."
-Thomas Edison (1847-1931)



"Heinrich Moser" wrote:

> Hi!
>
> We have a large access application (>100MB mdb with forms and reports,
> some mde libraries, some additional files) that we want to deploy to
> user's computers (data is stored in an SQL Server DB).
>
> Back in the old days of Windows XP, life was "easy": You created an
> installer that installed your application to C:\Program
> Files\Whatever. Since every user (usually) had local administrative
> access, it did not matter that the contents of the mdb were modified
> during normal operation (temporary local tables being modified,
> temporary local querys being created, tables being de-/attached,
> report settings being changed etc.).
>
> Now, in the days of Vista and Windows 7, users don't have write access
> to C:\Program Files, which is a good thing in general, but it breaks
> "classical" system-wide-installed mdb-based applications. Of course,
> there are a few obvious ways to overcome this problem, e.g.:
>
> (a) Give all users write access to C:\Program Files\Whatever.
>
> (b) Install the application to every user's home directory
> (C:\Users\username\AppData\...).
>
> Clearly, (a) is ugly from a security point-of-view and (b) is ugly
> from a maintainance point-of-view (think about updates etc.).
>
> Since I'm surely not the only one having this problem, I'd like to ask
> for opinions on this issue. Maybe there's a third way or even a
> well-established "best practices" guide for deploying mdb-based
> applications in environments where users are not local admins?
>
> Greetings and TIA,
> Heinrich
>

Heinrich Moser <(E-Mail Removed)> wrote:

>(b) Install the application to every user's home directory
> (C:\Users\username\AppData\...).
>
>Clearly, (a) is ugly from a security point-of-view and (b) is ugly
>from a maintainance point-of-view (think about updates etc.).

I completely agree with b. And the free Auto FE Updater supports
option b quite nicely. All you do is use the %appdata% variable in
the INI setup file and it will automatically create the folder in the
users Apps folder be in Windows XP or Vista.

I specifically created the Auto FE Updater utility so that I could
make changes to the FE MDE as often as I wanted and be quite confident
that the next time someone went to run the app that it would pull in
the latest version. For more info on the errors or the Auto FE
Updater utility see the free Auto FE Updater utility at
http://www.granite.ab.ca/access/autofe.htm at my website to keep the
FE on each PC up to date.

Note that the term home directory is, I think, a specific Windows
networking term and thus the IT dept may have the home directory be on
a user specific folder on the server so it gets backed up.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/

On Fri, 05 Jun 2009 03:43:01 -0700, Jack Leach wrote:

> I don't get too much into this myself, but the 'best practice' seems to
> be to put the app into the "Users\username\AppData\" folder, as it's the
> only one we can always be sure of the user having full read/write
> permissions (trying to give the user permissions to Program Files is
> probably not a good idea... there's a reason its blocked).
>
> As far as incorporating this into updates, you can use environment
> variables in your install procedure to come up with this location:
>
> "C:\Users\%USERNAME%\AppData\etc"
>
> this %variable% format can be used inside a batch, or you can get the
> same result in VBA with the Environ() function, thought it is generally
> recommended to use the API defined for this purpose. Go to
> mvps.org/access and seach the APIs section for Get Special Folder
>
> AFIAK, this is the only way to make sure everything works smoothly with
> Vista.

I just put my apps in their own folder off the C: root. I've never had a
Vista problem with that so far.


--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

"Rick Brandt" <(E-Mail Removed)> wrote in message
news:BatWl.8724$(E-Mail Removed)...

>
> I just put my apps in their own folder off the C: root. I've never had a
> Vista problem with that so far.
>
> --
> Rick Brandt, Microsoft Access MVP

The above is exactly what I started doing when vista hit the scene.

A simple folder in drive c: has worked very well for me. No problems, and in
many ways it simplifies installing.

I also have some applications that install to:

C:\Documents and Settings\All Users\Application Data\

Thus,my application world be something like:

C:\Documents and Settings\All Users\Application
Data\MyCusttomDir\accounting.mdb

The above dir is generally "hidden" by default, and can often be missed when
a computer is being backed up, but it is writable, and the path name does
not change from computer to computer (however, in the future who knows).

To the OP:

I have an inno install script sample and talk about deploying updates to
access in a runtime environment here:

http://www.members.shaw.ca/AlbertKal...ime/Index.html

The above tips would also apply to the full edition of ms-access.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
(E-Mail Removed)

=?Utf-8?B?SmFjayBMZWFjaA==?= <dymondjack at hot mail dot com> wrote
in news:ECC11C7A-3530-49BD-9DC0-(E-Mail Removed):

> I don't get too much into this myself, but the 'best practice'
> seems to be to put the app into the "Users\username\AppData\"
> folder, as it's the only one we can always be sure of the user
> having full read/write permissions (trying to give the user
> permissions to Program Files is probably not a good idea...
> there's a reason its blocked).

You wouldn't set permissions on the Program Files folder, but on
your own app's folder. As long as the traverse folders setting is on
(which is the default policy), a read-only parent folder won't
prevent setting write permissions on a child folder.

> As far as incorporating this into updates, you can use environment
> variables in your install procedure to come up with this location:
>
> "C:\Users\%USERNAME%\AppData\etc"

Don't do that. What you want is to use the %UserProfile% folder,
which will be C:\Users\%USERNAME% on Vista, and C:\Documents and
Settings\%USERNAME% on default WinXP and Win2K setups. But it may
not be -- user profiles may be stored on a server, or they may be on
a different drive. For instance, I set up my old Win2K desktop so
that the user profiles are on drive E:, which is my data drive (C:
is the OS only, D: is for programs, E: for data).

> this %variable% format can be used inside a batch, or you can get
> the same result in VBA with the Environ() function, thought it is
> generally recommended to use the API defined for this purpose. Go
> to mvps.org/access and seach the APIs section for Get Special
> Folder

Don't hardwire any part of the folder before your own app's folder
name. Use the API call to get the folder location.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

Rick Brandt <(E-Mail Removed)> wrote in
news:BatWl.8724$(E-Mail Removed):

> I just put my apps in their own folder off the C: root. I've
> never had a Vista problem with that so far.

Do you set your Access app shortcuts to run as administrator?

Or do you set the read/write permissions on your app folder
specifically?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Albert D. Kallal" <(E-Mail Removed)> wrote in
news:(E-Mail Removed):

> "Rick Brandt" <(E-Mail Removed)> wrote in message
> news:BatWl.8724$(E-Mail Removed)...
>
>> I just put my apps in their own folder off the C: root. I've
>> never had a Vista problem with that so far.
>
> The above is exactly what I started doing when vista hit the
> scene.
>
> A simple folder in drive c: has worked very well for me. No
> problems, and in many ways it simplifies installing.

I would delete your app if you did that, because I don't want any
apps installed in the root of my C: drive. That has been off-limits
to users since Windows 2000. The only apps that end up installing
stuff there in my experience are Open-Source apps created by
non-Windows users who don't have a clue how to write a setup script
that respects Windows standard locations.

> I also have some applications that install to:
>
> C:\Documents and Settings\All Users\Application Data\
>
> Thus,my application world be something like:
>
> C:\Documents and Settings\All Users\Application
> Data\MyCusttomDir\accounting.mdb

There was a recent discussion in one of the Access newsgroups that
the API call for this returns something different in Vista than in
WinXP and before. That is, the call in WinXP returned the All
Users\Application Data\ folder, but in Vista it returns the programs
folder. That individual reported that in Vista the All
Users\Application Data\ folder is read-only for users (as opposed to
in WinXP where users have full control).

I can't confirm any of this, but the upshot of it was that in Vista
you had to install the app in the user's AppData folder, so if
multiple users used a workstation, it would end up with multiple
copies of your front end. That doesn't sound like a disaster,
particularly if you're using an updater like Tony's, but it does
violate my esthetic principles of keeping things as simple as
possible.

[]

> To the OP:
>
> I have an inno install script sample and talk about deploying
> updates to access in a runtime environment here:
>
> http://www.members.shaw.ca/AlbertKal...ime/Index.html
>
> The above tips would also apply to the full edition of ms-access.

I don't see anything about it in the article at the URL above, but
are you setting user permissions in your Inno script? I would think
that many IT shops would have a major problem with this. Even
QuickBooks doesn't change the default permissions on its own folder
-- instead it requires you to run with something more than
user-level permissions. Me, well, I make my clients run with
user-level permissions and manually change the permissions on the
Intuit folder (so that all the versions of QB installed under that
will inherit the read/write permissions for users), but I am
supporting individual users rather than large workgroups or more.

There is a reason why Microsoft locks down the root of C: and the
programs and Windows folders -- it's required to implement safety
for LUA, and is one of the principles that led them to virtualize
several folders in Vista (so that apps that misbehaved in regard to
security could continue to operate).

Microsoft is doing the right thing security-wise.

We should adapt to that, instead of subverting it, in my opinion.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Albert D. Kallal" <(E-Mail Removed)> wrote:

>I also have some applications that install to:
>
>C:\Documents and Settings\All Users\Application Data\

And that works in Vista? My impression was that only admins could
update All Users. At least the desktop shortcuts anyhow. I disabled
that functionality in the Auto FE Updater for Windows Vista.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/