How to force my app to use my MDW in fileserver environment

[Guest]

This might be a long question, so please accept my apologies up front...

Scenario: I have developed an access application (2003) that needs to be
secure, so I have created my own MDW file to go with it. This application
will run in a fileserver / multiuser environment, so I need the MDW file (and
the BE) to be on the fileserver and the FE to to be on each client machine.
Bearing in mind that I don't know where the MDW will reside when I send the
application out to the user, I have configured the system to allow the user
to select the location of the central MDW after they load and login to the
FE. To allow the user to login in to the FE, a local MDW (with a "severely
restricted" User ID and Group) is installed on the same machine as the FE.
The whole kit'n'caboudle is also packaged using ADE as most users haven't got
Access. The problem arises when the app gets installed on a machine that
already has a version of Access (and therefore an existing MDW) on it.

No problem thinks I - just define my system such that if someone logs in
using "Admin" they will only be able to see a cutdown version of the system's
main form. This would just allow them to establish a connection to my
(centrally) located MDW and create a new login ID. Then when they close and
re-open the app, they can sign in with their new ID using my MDW and away
they go.

However, what I didn't account for was that the "Admin" user / "Admins"
group on the existing MDW may have been restricted or even removed.
Effectively this means that I can't define my app to "respond" to the
existing MDW as I can't guarantee whether any particular user or group will
exist in that MDW.

On the flip side, I don't want to "force" the FE version of my app to use my
local MDW by getting the ADE package to use the /wkgrp switch as I feel that
the users aren't sufficiently savvy to remove it once the system is up and
running. As far as I can see at the moment, I'm in a real Catch-22 situation,
but I can't figure out what the alternative might be.

If anyone has any ideas or recommendations, I would be very grateful.

 

[Joan Wild]

Scenario: I have developed an access application (2003) that needs to
be secure, so I have created my own MDW file to go with it. This
application will run in a fileserver / multiuser environment, so I
need the MDW file (and the BE) to be on the fileserver and the FE to
to be on each client machine. Bearing in mind that I don't know where
the MDW will reside when I send the application out to the user

Why not? Can't you just put it in the same folder as the BE?

, I

have configured the system to allow the user to select the location
of the central MDW after they load and login to the FE. To allow the
user to login in to the FE, a local MDW (with a "severely restricted"
User ID and Group) is installed on the same machine as the FE. The
whole kit'n'caboudle is also packaged using ADE as most users haven't
got Access. The problem arises when the app gets installed on a
machine that already has a version of Access (and therefore an
existing MDW) on it.

Again, I don't see the problem. If your MDW is installed in the same folder
as the FE, and you provide a desktop shortcut that points to it, an existing
mdw won't matter.

No problem thinks I - just define my system such that if someone logs
in using "Admin" they will only be able to see a cutdown version of
the system's main form. This would just allow them to establish a
connection to my (centrally) located MDW and create a new login ID.

I don't understand. How would they 'establish a connection' to your MDW on
the server, once Access is open?

However, what I didn't account for was that the "Admin" user /
"Admins" group on the existing MDW may have been restricted or even
removed. Effectively this means that I can't define my app to
"respond" to the existing MDW as I can't guarantee whether any
particular user or group will exist in that MDW.

You can always be sure that the Admin User exists, and the Users Group
exists. These cannot be deleted, and everyone is always a member of the
Users Group.

 

[Joan Wild]

Huw Davies wrote:

I have another thought. How many security groups do you have in your mdw?

 

[Guest]

Huw Davies wrote:

I have another thought. How many security groups do you have in your mdw?

Joan,

Many thanks for coming back to me so quickly, and please accept my apologies
for my delay in replying to your reply.

Firstly, I'm sorry, but I don't quite understand what you mean by "security
groups" in your second post - I've been developing my Access skills over the
last 12 months, but I've only had the need (aka courage) to dip into security
over the last week or two, so some of the terminology has still to embed
itself in my head (aka block of wood!).8=)

Secondly, reading your first post, I think that my inexperience may have led
me to incorrectly describe my problem, so what follows is an attempt to put
it in a more logical way - I do desperately need your help, so I hope this
helps you to help me. (This may take quite a while for me to write, because
I'm still not sure that I understand the why's and wherefore's of Access
security, but what the hey!). It is also highly likely that the problems that
I am envisaging and the threads of logic I have used to envisage them are
entirely flawed, but again, I'm hoping that if I am on totally the wrong
page, that you'll give me a quick kick in pants and set me right.

Although the first implementation of the system I have written is for a
school only 300 yards away (and which I can visit at the drop of a hat), I
hope to be able to present it to many other schools around the area or even
further afield where it won't be possible for me to do the installation
myself. I envisaged therefore to be able to send it out on a CD as an ADE
packaged solution that would work whatever their configuration (naive I know,
but I live in hope).

So the idea would be that the user would first install the package on their
fileserver which would comprise both BE and MDW (so that all clients use the
same MDW). They would then install the FE on each client PC. In order to
allow the FE to fireup, (most likely on a machine that had no Access
installed), I thought that I could also get them to put a (temporary) copy of
the MDW on the client PC. Call the fileserver MDW as MDWServer, and the
client one as MDWClient.

The user would load fire up the client based FE which would immediately see
the MDWClient and using a "limited access" login ID I provide, and get
through to a configuration form. On this form, I have placed a toolbar with
the Workgroup Administrator icon. By pressing this, the user can than join to
the MDWServer (wherever it may be, e.g T:\My Documents, or V:\Programs, etc).

I therefore didn't want to force the ADE package to automatically configure
the desktop shortcut to use the MDWClient as it would always use this
whenever the user double-clicked the shortcut - thereby ignoring the contents
of the MDWServer.

I tried this out on a PC without Access installed at it seemed to work fine,
but when I loaded the package on a PC that had Access, and fired it up it
didn't work. The system started without any request for a logon ID, and then
proceeded to tell me that I didn't have permission to run the initial
configuration form. Needless to say, I couldn't go any further.

My assumption from this was that the system recognised the presence of a
standard system.mdw and attempted to use the Admin user of that MDW to grant
access to my application, thereby completely ignoring the presence of my
MDWClient.

As I said above, it is highly likely that I still don't understand the
complexities of the way mdb/mde files interact with mdw files and that my
logic is wrong, but I would like to be able to provide something to the users
that a) is as simple as possible to implement, b) user a single MDW, and c)
can work in a fileserver environment with client PC's that may or may not
have Access.

Again, I've probably rambled on for too long, but I do appreciate your help.

Sincerest regards,

Huw.

 

[Joan Wild]

Firstly, I'm sorry, but I don't quite understand what you mean by
"security groups" in your second post - I've been developing my

What version of Access are you using, and how did you setup security - using
the security wizard?
When you set up security, you set up security groups. Every workgroup file
comes with Admins Group and Users Group. Part of implementing security is
to remove all permissions from the Users Group, and create your own Group(s)
and assign permissions to these groups. So my question is how many security
Groups did you set up?

So the idea would be that the user would first install the package on
their fileserver which would comprise both BE and MDW (so that all
clients use the same MDW). They would then install the FE on each
client PC. In order to allow the FE to fireup, (most likely on a
machine that had no Access installed), I thought that I could also
get them to put a (temporary) copy of the MDW on the client PC. Call
the fileserver MDW as MDWServer, and the client one as MDWClient.

I don't think this is necessary. Can't you have them install the FE in the
same folder? Maybe c:\Program Files\whatever
You can provide them with a desktop shortcut, and instructions on how to
edit the target to point to the workgroup file on the server.
It may be possible though, that you won't even need a workgroup file,
depending on the answer to my question above.

The user would load fire up the client based FE which would
immediately see the MDWClient and using a "limited access" login ID I
provide, and get through to a configuration form. On this form, I
have placed a toolbar with the Workgroup Administrator icon. By
pressing this, the user can than join to the MDWServer (wherever it
may be, e.g T:\My Documents, or V:\Programs, etc).

Yes but that will make your MDWServer the default for all Access sessions.
The users may not want that, if they have other non-secured databases. You
shouldn't force them to make your's the default. You need to provide them a
desktop shortcut that points to the right location.

I tried this out on a PC without Access installed at it seemed to
work fine, but when I loaded the package on a PC that had Access, and
fired it up it didn't work. The system started without any request
for a logon ID, and then proceeded to tell me that I didn't have
permission to run the initial configuration form. Needless to say, I
couldn't go any further.

Your initial configuration form would need to have read permissions for the
built-in Users Group.

Again, if you have only one security Group, post back as there's a better
way.

 

[Guest]

What version of Access are you using, and how did you setup security - using
the security wizard?
When you set up security, you set up security groups. Every workgroup file
comes with Admins Group and Users Group. Part of implementing security is
to remove all permissions from the Users Group, and create your own Group(s)
and assign permissions to these groups. So my question is how many security
Groups did you set up?


I don't think this is necessary. Can't you have them install the FE in the
same folder? Maybe c:\Program Files\whatever
You can provide them with a desktop shortcut, and instructions on how to
edit the target to point to the workgroup file on the server.
It may be possible though, that you won't even need a workgroup file,
depending on the answer to my question above.


Yes but that will make your MDWServer the default for all Access sessions.
The users may not want that, if they have other non-secured databases. You
shouldn't force them to make your's the default. You need to provide them a
desktop shortcut that points to the right location.


Your initial configuration form would need to have read permissions for the
built-in Users Group.

Again, if you have only one security Group, post back as there's a better
way.

Joan,

I'm tempted to ask have you got nothing better to do than to help poor
schmucks like me - but I won't. I'm just glad you're out there right now.

I'm using Access 2003 with ADE to do the packaging. I started using the
Security Wizard to setup the first group (or maybe two) but I then tinkered
with the MDW manually.

I'm sorry I didn't understand your question about security groups first time
round - in my head I just call them "groups" and I envisaged that "security
groups" were some other complex beast that I hadn't come across - please
excuse my stupidity and I hope the following is what you're after:

Apart from the Admins and Users groups, from which I (initially) revoked all
permissions, I have 5 other groups. One of these, called InitialLogon has
only one user - called New System. InitialLogon is the group that only has
permission to access the configuration form (New System also belongs to the
Users group - but no other groups).

Also, I now see your point about using the desktop shortcut to link to the
server-based MDW. I've read so many books and articles over the last couple
of weeks, that I should have picked that up, but you've now made it click.
You're absolutely right that I don't want to make my MDW the default for
every database on their system - it would be assuming a responsibility I
don't want (but wait a minute, think of the revenue I could get from the
inevitable calls for support - only joking!!).

Once again, many thanks for your continued support.

Huw.

 

[Joan Wild]

I'm tempted to ask have you got nothing better to do than to help poor
schmucks like me - but I won't. I'm just glad you're out there right
now.

Not to worry, I do have a life. I just like helping people.

Apart from the Admins and Users groups, from which I (initially)
revoked all permissions, I have 5 other groups. One of these, called
InitialLogon has only one user - called New System. InitialLogon is
the group that only has permission to access the configuration form
(New System also belongs to the Users group - but no other groups).

OK, if you had only 1 group, then there is a way to secure a database but
not require a workgroup file.

You could give the Users Group permission to the configuration form so that
if they do have Access installed, they'll be able to open the form. However
I think it better to provide a shortcut on the desktop.

Once again, many thanks for your continued support.

You're welcome!

 

[Guest]

Not to worry, I do have a life. I just like helping people.

OK, if you had only 1 group, then there is a way to secure a database but
not require a workgroup file.

You could give the Users Group permission to the configuration form so that
if they do have Access installed, they'll be able to open the form. However
I think it better to provide a shortcut on the desktop.


You're welcome!

Well it's too late now to mess about (being just gone midnight, I need my
beauty sleep), but I'll re-configure using your recommendations in the
morning. If I don't post back, please assume it's all worked and that my life
has just got that little bit easier. (Until I hit the next problem of course!
;=))