WARNING: Do not use Vista for multiple versions of Access!

"David W. Fenton" wrote in
. 1:

"David W. Fenton" wrote in
. 1:

"Allen Browne" wrote in
:

Have attempted to incorporate the various workarounds in this
article:
Errors using multiple versions of Access under Vista
at:
http://allenbrowne.com/bug-17.html
with the advantages and limitations of each option.

Well, I must say I misunderstood something. I thought you could
permanently define a shortcut to run as administrator (without
writing code to invoke the RunAs service). That would be a really
stupid design on MS's part.

It seems from what I've read that you can change the an executable
to run with admin privileges, as opposed to a shortcut. Can
someone investigate and see if you could change each of your
non-A2K7 MSACCESS.EXE files to always run with admin privileges by
right clicking them and changing the appropriate properties?

Also, there's apparently group policies that goven how UAC works.
Could someone look at those and see if they can be altered partially
to make this problem go away? It may be that the individual policies
don't control this, and the only way is to turn it off entirely, but
it's worth a look.

(sorry to be asking others to do this, but I'm very concerned about
this for the future, about a year from now when my first clients get
Vista, and I don't have any way to test it myself -- no hardware to
run it on)

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

"David W. Fenton" wrote in
. 1:

"David W. Fenton" wrote in
. 1:

"David W. Fenton" wrote in
. 1:

"Allen Browne" wrote in
:

Have attempted to incorporate the various workarounds in this
article:
Errors using multiple versions of Access under Vista
at:
http://allenbrowne.com/bug-17.html
with the advantages and limitations of each option.

Well, I must say I misunderstood something. I thought you could
permanently define a shortcut to run as administrator (without
writing code to invoke the RunAs service). That would be a
really stupid design on MS's part.

It seems from what I've read that you can change the an
executable to run with admin privileges, as opposed to a
shortcut. Can someone investigate and see if you could change
each of your non-A2K7 MSACCESS.EXE files to always run with admin
privileges by right clicking them and changing the appropriate
properties?

Also, there's apparently group policies that goven how UAC works.
Could someone look at those and see if they can be altered
partially to make this problem go away? It may be that the
individual policies don't control this, and the only way is to
turn it off entirely, but it's worth a look.

(sorry to be asking others to do this, but I'm very concerned
about this for the future, about a year from now when my first
clients get Vista, and I don't have any way to test it myself --
no hardware to run it on)

Sorry to draw this out -- I'm reading and discovering things as I
go.

In the microsoft.public.windows.vista.security group, there are a
number of posts on UAC. Here are some message IDs that might provide
suggestions for resolving this issue:



The followups to that post are pretty illuminating, especially:



Another article pointed me to this:

http://windowsconnected.com/blogs/je.../12/21/97.aspx

which describes how to create a "run-time manifest" that allows you
to override default security settings. I don't know how the details
work, but maybe someone could look at it and try to figure it out.

The thread starting with this post:



is a good walk-through of the way UAC works and why it's important.

I'd be interested if anyone can look through some of those resources
and see if it's possible to figure out a reasonable workaround for
the coexistence problem short of turning off UAC.

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