Front Ends on shared XP Professional boxes

[Roald Oines]

My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I have
several Access databases with FE .mdb/.mde files in both versions, and I
have the users run .bat files that make a folder in the C:\ root
directory, copy the FEs from the file server to that folder and put a
shortcut on the start menu. All is working fine, except that when the
clerical users are backing up a peer (and using the peer's XP box
instead of their own), they get a message that the FE file is read-only.
The FEs make temporary queries and local tables in some routines, so
this could prevent them from working.

As near as I can tell, it's a folder/file permissions issue (the file
attributes don't indicate RO). I haven't found any batch commands to
change file or folder permissions, and the only thing I can think of
off-hand is to copy the FEs to the TEMP folder, which doesn't seem
sensible to me (and I'm not even sure if it'd solve the problem). Has
anyone here found an easy solution to this issue?

TIA.

--
Please remove the under_scores if replying by mail.

[Allen Browne]

Do your users log into Win XP with administrative rights, or as a regular
user?

It may be that they do not have full permissions for:
- the folder where the batch file is installing the FE, or
- the network share where the back end is, or
- the folder where system.mdw is.

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Roald Oines" <r_*******@bres nan.net> wrote in message
news:bq******** ************@br esnan.com...

My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I have
several Access databases with FE .mdb/.mde files in both versions, and I
have the users run .bat files that make a folder in the C:\ root
directory, copy the FEs from the file server to that folder and put a
shortcut on the start menu. All is working fine, except that when the
clerical users are backing up a peer (and using the peer's XP box
instead of their own), they get a message that the FE file is read-only.
The FEs make temporary queries and local tables in some routines, so
this could prevent them from working.

As near as I can tell, it's a folder/file permissions issue (the file
attributes don't indicate RO). I haven't found any batch commands to
change file or folder permissions, and the only thing I can think of
off-hand is to copy the FEs to the TEMP folder, which doesn't seem
sensible to me (and I'm not even sure if it'd solve the problem). Has
anyone here found an easy solution to this issue?

[Roald Oines]

Allen Browne <Al*********@Se eSig.Invalid> wrote:

Do your users log into Win XP with administrative rights, or as a
regular user?

It may be that they do not have full permissions for:
- the folder where the batch file is installing the FE, or
- the network share where the back end is, or
- the folder where system.mdw is.
They log in as regular users as far as XP is concerned. I'm pretty sure
it's the folder where the FE is that's the problem (I looked at the same
folder on my machine and it only has full permissions for me and
administrators) . The shortcut the batch puts on their start menu points
to an .mdw on the network, and the users have full permissions on that
folder and the folders where the BEs live.
"Roald Oines" <r_*******@bres nan.net> wrote in message
news:bq******** ************@br esnan.com...

My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I
have several Access databases with FE .mdb/.mde files in both
versions, and I have the users run .bat files that make a folder in
the C:\ root directory, copy the FEs from the file server to that
folder and put a shortcut on the start menu. All is working fine,
except that when the clerical users are backing up a peer (and
using the peer's XP box instead of their own), they get a message
that the FE file is read-only. The FEs make temporary queries and
local tables in some routines, so this could prevent them from
working.

As near as I can tell, it's a folder/file permissions issue (the
file attributes don't indicate RO). I haven't found any batch
commands to change file or folder permissions, and the only thing I
can think of off-hand is to copy the FEs to the TEMP folder, which
doesn't seem sensible to me (and I'm not even sure if it'd solve
the problem). Has anyone here found an easy solution to this issue?

--
Please remove the under_scores if replying by mail.

[Darryl Kerkeslager]

Each user will need Administrative rights to the shared PC. Under My
Computer, right click, and you will see a menu item "Manage" ...

Unfortunately, I'm at my Windows 98 machine, and I don't exactly recall
where it is in the Management section, but *somewhere* in there is a place
where you assign permissions to the PC.

Darryl Kerekslager
"Roald Oines" <r_*******@bres nan.net> wrote in message
news:7e******** ************@br esnan.com...

Allen Browne <Al*********@Se eSig.Invalid> wrote:

Do your users log into Win XP with administrative rights, or as a
regular user?

It may be that they do not have full permissions for:
- the folder where the batch file is installing the FE, or
- the network share where the back end is, or
- the folder where system.mdw is.
They log in as regular users as far as XP is concerned. I'm pretty sure
it's the folder where the FE is that's the problem (I looked at the same
folder on my machine and it only has full permissions for me and
administrators) . The shortcut the batch puts on their start menu points
to an .mdw on the network, and the users have full permissions on that
folder and the folders where the BEs live.
"Roald Oines" <r_*******@bres nan.net> wrote in message
news:bq******** ************@br esnan.com...
My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I
have several Access databases with FE .mdb/.mde files in both
versions, and I have the users run .bat files that make a folder in
the C:\ root directory, copy the FEs from the file server to that
folder and put a shortcut on the start menu. All is working fine,
except that when the clerical users are backing up a peer (and
using the peer's XP box instead of their own), they get a message
that the FE file is read-only. The FEs make temporary queries and
local tables in some routines, so this could prevent them from
working.

As near as I can tell, it's a folder/file permissions issue (the
file attributes don't indicate RO). I haven't found any batch
commands to change file or folder permissions, and the only thing I
can think of off-hand is to copy the FEs to the TEMP folder, which
doesn't seem sensible to me (and I'm not even sure if it'd solve
the problem). Has anyone here found an easy solution to this issue?

--
Please remove the under_scores if replying by mail.

[Tony Toews]

"Darryl Kerkeslager" <Ke*********@co mcast.net> wrote:

Each user will need Administrative rights to the shared PC. Under My
Computer, right click, and you will see a menu item "Manage" ...

No, no. In an ideal world users should never be administrators. All software
should be designed to be run as regular users. Unfortunately many of the developers,
including myself, run as administrators and thus are the major cause of this problem.

Running as administrator opens the door for malicious software much wider.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Tony Toews]

"Roald Oines" <r_*******@bres nan.net> wrote:

My company is in the process of updating PCs from NT4 to XP
Professional , along with moving from Office 97 to Office 2002. I have
several Access databases with FE .mdb/.mde files in both versions, and I
have the users run .bat files that make a folder in the C:\ root
directory, copy the FEs from the file server to that folder and put a
shortcut on the start menu. All is working fine, except that when the
clerical users are backing up a peer (and using the peer's XP box
instead of their own), they get a message that the FE file is read-only.
The FEs make temporary queries and local tables in some routines, so
this could prevent them from working.

As near as I can tell, it's a folder/file permissions issue (the file
attributes don't indicate RO). I haven't found any batch commands to
change file or folder permissions, and the only thing I can think of
off-hand is to copy the FEs to the TEMP folder, which doesn't seem
sensible to me (and I'm not even sure if it'd solve the problem). Has
anyone here found an easy solution to this issue?

From the limited research I've done on this topic such should be installed in the
users Documents and Settings folders. Some possible folders could be one of the
following environment variables:
ALLUSERSPROFILE =C:\Documents and Settings\All Users
APPDATA=C:\Docu ments and Settings\ttoews \Application Data
HOMEPATH=\Docum ents and Settings\ttoews
and subfolders there of of course.

From what I can recall every other folder is locked down when running as a user on a
Windows XP NTFS system. Also regular users can't create folders off the root
either.

Also note that 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.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

[Dan Morgan]

I solved this problem by using a vbscript to have each user install
the fe in their own profile:

dim wShell
dim strPathToInstal l
dim strShortCutInst all
dim objShortcut
dim fso

const PATHTOINSTALLPO INT = "pathtnetworkin stallpoint"

const PROGRAMTOINSTAL L = "somerogram.mdb "

set wShell = wscript.createo bject("wscrpt.s hell")

strPathToInstal l = wShell.specialf olders("MyDocum ents")
'the baove drops into my documents, you could put
'whereever you want

strShortCutInst all = wShell.specialf olders("Program s")

set fso = wscript.createo bject("scriptin g.filesystemobj ect")

fso.copyfile PATHTOINSTALLPO INT & PROGRAMTOINSTAL L,strPathToInst all &
"\",true

set fso = nothing

set objShortcut = wShell.createsh ortcut(strShort CutInstall & "\" &
PROGRAMTOINSTAL L & ".lnk")

objShortcut.tar getpath = strPathToInstal l & "\" & PROGRAMTOINSTAL L

objShortcut.win dowstyle = 1

objShortcut.sav e

set objShortcut = nothing

set wShell = nothing

"Roald Oines" <r_*******@bres nan.net> wrote in message news:<7e******* *************@b resnan.com>...

Allen Browne <Al*********@Se eSig.Invalid> wrote:

Do your users log into Win XP with administrative rights, or as a
regular user?

It may be that they do not have full permissions for:
- the folder where the batch file is installing the FE, or
- the network share where the back end is, or
- the folder where system.mdw is.
They log in as regular users as far as XP is concerned. I'm pretty sure
it's the folder where the FE is that's the problem (I looked at the same
folder on my machine and it only has full permissions for me and
administrators) . The shortcut the batch puts on their start menu points
to an .mdw on the network, and the users have full permissions on that
folder and the folders where the BEs live.
"Roald Oines" <r_*******@bres nan.net> wrote in message
news:bq******** ************@br esnan.com...
My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I
have several Access databases with FE .mdb/.mde files in both
versions, and I have the users run .bat files that make a folder in
the C:\ root directory, copy the FEs from the file server to that
folder and put a shortcut on the start menu. All is working fine,
except that when the clerical users are backing up a peer (and
using the peer's XP box instead of their own), they get a message
that the FE file is read-only. The FEs make temporary queries and
local tables in some routines, so this could prevent them from
working.

As near as I can tell, it's a folder/file permissions issue (the
file attributes don't indicate RO). I haven't found any batch
commands to change file or folder permissions, and the only thing I
can think of off-hand is to copy the FEs to the TEMP folder, which
doesn't seem sensible to me (and I'm not even sure if it'd solve
the problem). Has anyone here found an easy solution to this issue?

[Roald Oines]

Tony Toews <tt****@teluspl anet.net> wrote:

"Roald Oines" <r_*******@bres nan.net> wrote:

My company is in the process of updating PCs from NT4 to XP
Professional, along with moving from Office 97 to Office 2002. I
have several Access databases with FE .mdb/.mde files in both
versions, and I have the users run .bat files that make a folder in
the C:\ root directory, copy the FEs from the file server to that
folder and put a shortcut on the start menu. All is working fine,
except that when the clerical users are backing up a peer (and
using the peer's XP box instead of their own), they get a message
that the FE file is read-only. The FEs make temporary queries and
local tables in some routines, so this could prevent them from
working.

As near as I can tell, it's a folder/file permissions issue (the
file attributes don't indicate RO). I haven't found any batch
commands to change file or folder permissions, and the only thing I
can think of off-hand is to copy the FEs to the TEMP folder, which
doesn't seem sensible to me (and I'm not even sure if it'd solve
the problem). Has anyone here found an easy solution to this issue?

From the limited research I've done on this topic such should be
installed in the users Documents and Settings folders. Some
possible folders could be one of the following environment variables:
ALLUSERSPROFILE =C:\Documents and Settings\All Users
APPDATA=C:\Docu ments and Settings\ttoews \Application Data
HOMEPATH=\Docum ents and Settings\ttoews
and subfolders there of of course.
The first iteration of my batch tried to put the shortcut file into the
ALLUSERSPROFILE start menu -- I figured that would simplify things when
one user logged on to another user's box. Some of the users succeeded in
putting the shortcut there, others didn't (permissions error, IIRC), so
I rewrote the .bat file to put the shortcut in the current user's
profile start menu instead. I thought about putting the .mdb in the
Documents and Settings folder, but that's typically pointed to the
user's folder on the file server (which, since a server consolidation
project a few months ago, is located hundreds of miles from most of my
users).
From what I can recall every other folder is locked down when
running as a user on a Windows XP NTFS system. Also regular users
can't create folders off the root either.
FWIW, the batch didn't have any trouble creating a C:\DBs folder for any
of my users, and they're all regular users. Of course, the default
security settings at my company could certainly have non-standard
configurations.
Also note that 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.
I've looked at it but haven't gotten around to testing it in my
environment.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

--
Please remove the under_scores if replying by mail.

[Roald Oines]

Dan Morgan <us****@yahoo.c om> wrote:

I solved this problem by using a vbscript to have each user install
the fe in their own profile:

dim wShell
dim strPathToInstal l
dim strShortCutInst all
dim objShortcut
dim fso

const PATHTOINSTALLPO INT = "pathtnetworkin stallpoint"

const PROGRAMTOINSTAL L = "somerogram.mdb "

set wShell = wscript.createo bject("wscrpt.s hell")

strPathToInstal l = wShell.specialf olders("MyDocum ents")
'the baove drops into my documents, you could put
'whereever you want

strShortCutInst all = wShell.specialf olders("Program s")

set fso = wscript.createo bject("scriptin g.filesystemobj ect")

fso.copyfile PATHTOINSTALLPO INT & PROGRAMTOINSTAL L,strPathToInst all &
"\",true

set fso = nothing

set objShortcut = wShell.createsh ortcut(strShort CutInstall & "\" &
PROGRAMTOINSTAL L & ".lnk")

objShortcut.tar getpath = strPathToInstal l & "\" & PROGRAMTOINSTAL L

objShortcut.win dowstyle = 1

objShortcut.sav e

set objShortcut = nothing

set wShell = nothing

Thanks Dan, I've saved a copy of this script. Unfortunately, in my
company the My Documents folder points to the user's folder on the file
server rather than the user's C: drive. If the file servers were local
to the users, that may still provide adequate performance, but most of
my users are hundreds of miles from their file servers since a server
consolidation project a few months ago.

"Roald Oines" <r_*******@bres nan.net> wrote in message
news:<7e******* *************@b resnan.com>...

Allen Browne <Al*********@Se eSig.Invalid> wrote:
> Do your users log into Win XP with administrative rights, or as a
> regular user?
>
> It may be that they do not have full permissions for:
> - the folder where the batch file is installing the FE, or
> - the network share where the back end is, or
> - the folder where system.mdw is.

They log in as regular users as far as XP is concerned. I'm pretty
sure it's the folder where the FE is that's the problem (I looked
at the same folder on my machine and it only has full permissions
for me and administrators) . The shortcut the batch puts on their
start menu points to an .mdw on the network, and the users have
full permissions on that folder and the folders where the BEs live.

> "Roald Oines" <r_*******@bres nan.net> wrote in message
> news:bq******** ************@br esnan.com...
>> My company is in the process of updating PCs from NT4 to XP
>> Professional, along with moving from Office 97 to Office 2002. I
>> have several Access databases with FE .mdb/.mde files in both
>> versions, and I have the users run .bat files that make a folder
>> in the C:\ root directory, copy the FEs from the file server to
>> that folder and put a shortcut on the start menu. All is working
>> fine, except that when the clerical users are backing up a peer
>> (and using the peer's XP box instead of their own), they get a
>> message that the FE file is read-only. The FEs make temporary
>> queries and local tables in some routines, so this could prevent
>> them from working.
>>
>> As near as I can tell, it's a folder/file permissions issue (the
>> file attributes don't indicate RO). I haven't found any batch
>> commands to change file or folder permissions, and the only
>> thing I can think of off-hand is to copy the FEs to the TEMP
>> folder, which doesn't seem sensible to me (and I'm not even sure
>> if it'd solve the problem). Has anyone here found an easy
>> solution to this issue?

--
Please remove the under_scores if replying by mail.

[Darryl Kerkeslager]

"Roald Oines" <r_*******@bres nan.net> wrote:

Unfortunatel y, in my
company the My Documents folder points to the user's folder on the file
server rather than the user's C: drive. If the file servers were local
to the users, that may still provide adequate performance, but most of
my users are hundreds of miles from their file servers since a server
consolidation project a few months ago.

Same here. I understand Tony's point that granting Admin rights may not be
the tightest security, but, it does solve the problem.
Darryl Kerkeslager