On Jan 01 2005, 06:18 pm, "David W. Fenton" <dXXXfenton (AT) bway (DOT) net.invalid>
wrote in news:Xns95D1BB9EBEAEEdfentonbwaynetinvali (AT) 24 (DOT) 168.128.74:

Yes, this and practically all other Office settings can be set before
installation, as well as installation states of all Office components. Take
a look at the Deployment Guide in the Office Resource Kit at
http://office.microsoft.com/en-us/as...401921033.aspx

It may take a few hours to read through, and a few more hours to
implement, but it will simplify Office installation and administration a
lot.

As far as the macro security in A2003, there is a workaround for cases when
it is not set to Low, which involves creating an Access instance from an
external launcher and setting a property of the instance that supresses the
warnings. There is a KB article with some sample code - post back if you
can't find it, I'll dig out the link.

And of course, you can always create self-signed certificates and install
them on all machines that will run your application, which is also
described somewhere on MS site.

--
remove a 9 to reply by email

Dimitri Furman wrote:
With a certificate, doesn't it come up with a warning anyway?

--
This sig left intentionally blank

I have a problem with the statement that "Access2000 and Access2003 running
is entirely seamless".

My application runs perfectly in Access2000, as source code or as a runtime.
However, the runtime will NOT run on Access 2003. When I try it, the A2003
fails on startup with a runtime error, and when I look at the reasons, it
appears that the MS Access 9.0 Object Library has been replaced with MS
Access 10.0 Object Library, which appears not to be compatible. I have
included the 9.0 library in the installed code, but it makes no difference.
Even when I try to run it from the source code, it fails with the typical
"Missing references" type errors.

It's possible I am doing something stupid, but if I am, I can't get it going
under A2003. I don't have a copy of A2003 developer, so can't distribute
A2003.

Hans Karman, Canberra, Australia


"David W. Fenton" <dXXXfenton (AT) bway (DOT) net.invalid> wrote

On Jan 02 2005, 07:46 am, Trevor Best <nospam (AT) besty (DOT) org.uk> wrote in
news:41d7ed3e$0$21323$db0fefd9 (AT) news (DOT) zen.co.uk:

Yes for Medium and High, but it doesn't happen if you add the author to the
list of Trusted Publishers. It turns out thought that you cannot add a
self-signed certificate to the list of Trusted Publishers on any machine
other than the one where it was created. So this is hardly an option for
application deployment, after all.

--
remove a 9 to reply by email

"Darryl Kerkeslager" <Kerkeslager (AT) comcast (DOT) net> wrote in
news:4YWdnTcMfccBo0rcRVn-hQ (AT) comcast (DOT) com:

It would be just as secure as every single previous version of
Access that has ever existed.

In other words, as far as I'm concerned, a complete non-issue.

This is an area (code signing) where I believe MS has really screwed
up -- the certificates cost way too much for the casual programmer,
who is then forced to use the non-secure methods to run her
applications.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

Dimitri Furman <dfurman (AT) cloud99 (DOT) net> wrote in
news:Xns95D2684C749A9dfurmancloud99 (AT) 127 (DOT) 0.0.1:

If I create the certificate on the Windows Terminal Server, and only
WTS users are using A2K3 to run the app (which is actually in A2K
format), won't that do the job?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

David W. Fenton wrote:
Too true, we're going to get asked if we want to execute msaccess.exe
next because it's an executable and might contain malicious code, oh
hang on, if msaccess.exe (or any exe) is on a network drive and you're
running Win2003 you already do. This is getting far too namby pamby,
what the hell do MS think we have antivirus programs and firewalls for?

Remember that old joke about MS vs GM? When the GM man said a MS airbag
would ask "are you sure?" before deploying? It would be funny if it
wasn't so near the truth.

--
This sig left intentionally blank

Well, I'm glad you started this thread. They've begun [upgrading] all our
PCs (slowly) to XP, and the first user, upon seeing the XP security warning
message, read it just enough to tell me that my application "won't work
anymore". For her, that was it, end of story. Never mind that the actual
message said nothing of the sort; she just saw an unfamiliar message, and
clicked Cancel.


Darryl Kerkeslager

In your install or update program, you can set the following registry values
to prevent the security warning:

If you have Admin rights:
HKLM\Software\Microsoft\Office\11.0\Access\Securit y\; ValueType: dword;
ValueName: Level; ValueData: 1;

If you have User rights:
HKCU\Software\Microsoft\Office\11.0\Access\Securit y\; ValueType: dword;
ValueName: Level; ValueData: 1;

- Steve

"Darryl Kerkeslager" <Kerkeslager (AT) comcast (DOT) net> wrote

On Jan 02 2005, 07:47 pm, "David W. Fenton" <dXXXfenton (AT) bway (DOT) net.invalid>
wrote in news:Xns95D2CA8DD92FBdfentonbwaynetinvali (AT) 24 (DOT) 168.128.78:

I suppose it would, although you would have to re-sign on TS every time you
release a new version of the app.

I think that using an external launcher to set AutomationSecurity property
is the most bullet-proof and hassle-free way of addressing macro security.
You can use VBS if you can't compile an executable for any reason. Here are
some details (sample VBS script towards the end):
http://office.microsoft.com/en-us/as...397921033.aspx

--
remove a 9 to reply by email