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_*******@bresnan.net> wrote in message
news:bq********************@bresnan.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*********@SeeSig.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_*******@bresnan.net> wrote in message
news:bq********************@bresnan.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_*******@bresnan.net> wrote in message
news:7e********************@bresnan.com...

Allen Browne <Al*********@SeeSig.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_*******@bresnan.net> wrote in message
news:bq********************@bresnan.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*********@comcast.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_*******@bresnan.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:\Documents and Settings\ttoews\Application Data
HOMEPATH=\Documents 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 strPathToInstall
dim strShortCutInstall
dim objShortcut
dim fso

const PATHTOINSTALLPOINT = "pathtnetworkinstallpoint"

const PROGRAMTOINSTALL = "somerogram.mdb"

set wShell = wscript.createobject("wscrpt.shell")

strPathToInstall = wShell.specialfolders("MyDocuments")
'the baove drops into my documents, you could put
'whereever you want

strShortCutInstall = wShell.specialfolders("Programs")

set fso = wscript.createobject("scripting.filesystemobject")

fso.copyfile PATHTOINSTALLPOINT & PROGRAMTOINSTALL,strPathToInstall &
"\",true

set fso = nothing

set objShortcut = wShell.createshortcut(strShortCutInstall & "\" &
PROGRAMTOINSTALL & ".lnk")

objShortcut.targetpath = strPathToInstall & "\" & PROGRAMTOINSTALL

objShortcut.windowstyle = 1

objShortcut.save

set objShortcut = nothing

set wShell = nothing

"Roald Oines" <r_*******@bresnan.net> wrote in message news:<7e********************@bresnan.com>...

Allen Browne <Al*********@SeeSig.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_*******@bresnan.net> wrote in message
news:bq********************@bresnan.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****@telusplanet.net> wrote:

"Roald Oines" <r_*******@bresnan.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:\Documents and Settings\ttoews\Application Data
HOMEPATH=\Documents 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.com> wrote:

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

dim wShell
dim strPathToInstall
dim strShortCutInstall
dim objShortcut
dim fso

const PATHTOINSTALLPOINT = "pathtnetworkinstallpoint"

const PROGRAMTOINSTALL = "somerogram.mdb"

set wShell = wscript.createobject("wscrpt.shell")

strPathToInstall = wShell.specialfolders("MyDocuments")
'the baove drops into my documents, you could put
'whereever you want

strShortCutInstall = wShell.specialfolders("Programs")

set fso = wscript.createobject("scripting.filesystemobject")

fso.copyfile PATHTOINSTALLPOINT & PROGRAMTOINSTALL,strPathToInstall &
"\",true

set fso = nothing

set objShortcut = wShell.createshortcut(strShortCutInstall & "\" &
PROGRAMTOINSTALL & ".lnk")

objShortcut.targetpath = strPathToInstall & "\" & PROGRAMTOINSTALL

objShortcut.windowstyle = 1

objShortcut.save

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_*******@bresnan.net> wrote in message
news:<7e********************@bresnan.com>...

Allen Browne <Al*********@SeeSig.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_*******@bresnan.net> wrote in message
> news:bq********************@bresnan.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_*******@bresnan.net> wrote:

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.

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

[Roald Oines]

Darryl Kerkeslager <Ke*********@comcast.net> wrote:

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

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.

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

Our IT department doesn't seem shy about granting Admin rights to
regular users when needed (we run a LOT of legacy software, front-ends
to other databases mostly, that won't run in NT under a regular
account), but I was hoping to avoid doing that.

--
Please remove the under_scores if replying by mail.

[Darryl Kerkeslager]

Two thoughts:

One of the reasons we are granted Admin rights to our own PCs is the
installation of certain software, notably Microsoft ActiveSync, for the Dell
Axim PDAs, which use MS Windows Mobile. This program must install a
synchronization folder usually named Pocket_PC_MyDocuments as a subfolder of
MyDocuments. This requires the user to be the installer, since
file-synchronization will not work correctly otherwise, and once installed,
you cannot move the MyDocuments folder without messing up synchronization,
nor can you move the Pocket_PC folder at all.

Second thought:

I have an identical setup to Roald's (the same issue effects Windows 2000),
and all my files for the front end are stored in a folder C:\ODIS.
Changing the folder to a location under the user's profile would be a large
pain, and would in fact create not only the same performance issues that
Roald mentioned, but other issues as well. And, this issue only effects the
one PC per office that administrative staff share when manning the reception
desk.

While I don't want to create security issues (as the most secure MS install
is insecure enough), I think that using this folder as it is, is necessary.
So, without granting Admin rights to the entire PC, is there another
solution? I have not tried this, but would it be possible to simply share
the folder among the users who will be logged on to that PC?

Darryl Kerkeslager

"Darryl Kerkeslager" <Ke*********@comcast.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" ...

"Tony Toews" <tt****@telusplanet.net> wrote: 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 Toews]

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

One of the reasons we are granted Admin rights to our own PCs is the
installation of certain software, notably Microsoft ActiveSync, for the Dell
Axim PDAs, which use MS Windows Mobile. This program must install a
synchronization folder usually named Pocket_PC_MyDocuments as a subfolder of
MyDocuments. This requires the user to be the installer, since
file-synchronization will not work correctly otherwise, and once installed,
you cannot move the MyDocuments folder without messing up synchronization,
nor can you move the Pocket_PC folder at all.
That bytes. My Palm is a bit troublesome in such respect but I can move the folder
to whereever I want.
I have an identical setup to Roald's (the same issue effects Windows 2000),
and all my files for the front end are stored in a folder C:\ODIS.
Changing the folder to a location under the user's profile would be a large
pain,
Why would this be a pain?
and would in fact create not only the same performance issues that
Roald mentioned, but other issues as well. And, this issue only effects the
one PC per office that administrative staff share when manning the reception
desk.
Performance? Ah, because the client PCs aren't on the same LAN as the backend?
While I don't want to create security issues (as the most secure MS install
is insecure enough), I think that using this folder as it is, is necessary.
So, without granting Admin rights to the entire PC, is there another
solution? I have not tried this, but would it be possible to simply share
the folder among the users who will be logged on to that PC?

Yes, you could change permissions on one, or more, folder(s) so that users have RWXD
permissions on it. If I understand your question properly.

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_*******@bresnan.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:\Documents and Settings\ttoews\Application Data
HOMEPATH=\Documents 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).

Ouch. Yeah, you do have some interesting configuration issues. I'm not at all
sure what the best answer is for you other than having to give all users permissions
to the previously mentioned C:\DBs folder.

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

[Darryl Kerkeslager]

"Tony Toews" <tt****@telusplanet.net> wrote:

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

Changing the folder to a location under the user's profile would be a largepain,

Why would this be a pain?

and would in fact create not only the same performance issues that
Roald mentioned, but other issues as well. And, this issue only effects theone PC per office that administrative staff share when manning the receptiondesk.

Performance? Ah, because the client PCs aren't on the same LAN as the

backend?

I began typing my answer, and realized that it doesn't apply - while the
MyDocuments folder is on the WAN, the entire profile is not (the backend is
on the same LAN). Nevertheless, even if the performance does not take a
hit, in order for me to move the frontend, and the several subfolders, from
C:\odis to C:\[username]\odis would take some recoding. Maybe not that much
now that I think about it.

Rats, maybe I just need to mull this over for a few weeks ....
Darryl Kerkeslager

[Roald Oines]

Tony Toews <tt****@telusplanet.net> wrote:
: "Roald Oines" <r_*******@bresnan.net> wrote:
:
<snip>
:
: Ouch. Yeah, you do have some interesting configuration issues.
: I'm not at all sure what the best answer is for you other than having
: to give all users permissions to the previously mentioned C:\DBs
: folder.
:
: Tony

Thanks -- I'm thinking that's the best solution. I know how to set
attributes in a batch file -- do you know if there's a way to share a
folder or set security options that way (I couldn't find anything in
help)? Otherwise I'll have to walk several, not-very-computer-literate
folks through that process over the phone.
--
Please remove the under_scores if replying by mail.

[Tony Toews]

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

I began typing my answer, and realized that it doesn't apply - while the
MyDocuments folder is on the WAN, the entire profile is not (the backend is
on the same LAN). Nevertheless, even if the performance does not take a
hit, in order for me to move the frontend, and the several subfolders, from
C:\odis to C:\[username]\odis would take some recoding. Maybe not that much
now that I think about it.
Why would it take some recoding?
Rats, maybe I just need to mull this over for a few weeks ....

Hey, that's what we're here for. To answer questions and challenge assumptions.

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

[David W. Fenton]

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:W6********************@comcast.com:

Two thoughts:

One of the reasons we are granted Admin rights to our own PCs is
the installation of certain software, notably Microsoft
ActiveSync, for the Dell Axim PDAs, which use MS Windows Mobile.
This program must install a synchronization folder usually named
Pocket_PC_MyDocuments as a subfolder of MyDocuments. This
requires the user to be the installer, since file-synchronization
will not work correctly otherwise, and once installed, you cannot
move the MyDocuments folder without messing up synchronization,
nor can you move the Pocket_PC folder at all.
The user should have ownership of their own My Documents folder.
This is the whole reason that in Win2K the user profiles were moved
out of the Windows/WinNT folder, so that the OS's home folder could
have reduced access for end users.

There is simply no excuse for any software at all needing
administrative rights to install. It may be able to install itself
only for the user running it, but it should still be able to
successfully install itself.

And, once installed, no software should require anything above user
rights to run. Any software that requires it is software you should
stop using.
Second thought:

I have an identical setup to Roald's (the same issue effects
Windows 2000), and all my files for the front end are stored in a
folder C:\ODIS. Changing the folder to a location under the user's
profile would be a large pain, and would in fact create not only
the same performance issues that Roald mentioned, but other issues
as well. And, this issue only effects the one PC per office that
administrative staff share when manning the reception desk.
Give full control on that folder to all users.
While I don't want to create security issues (as the most secure
MS install is insecure enough), I think that using this folder as
it is, is necessary. So, without granting Admin rights to the
entire PC, is there another solution? I have not tried this, but
would it be possible to simply share the folder among the users
who will be logged on to that PC?

Doesn't anyone learn even the barest basics of Windows
administration?

Logged in as an administrator, open Windows Explorer and browse to
the C:\ODIS folder.

Right click it and choose PROPERTIES, then SECURITY.

If the Users group has no setting already, add them and give them
full control of the folder.

Now, this only works if the folder already exists and you're
sittting at the PC and have an administrative logon available to
you. If you're having the user install programmatically, I don't
know how you'd do this. But the RunAs service exists precisely for
this purpose, to elevate privileges for the process involved so that
it can do things the user running it would otherwise be unable to
do.

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

[David W. Fenton]

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:du********************@comcast.com:

I began typing my answer, and realized that it doesn't apply -
while the MyDocuments folder is on the WAN, the entire profile is
not (the backend is on the same LAN). Nevertheless, even if the
performance does not take a hit, in order for me to move the
frontend, and the several subfolders, from C:\odis to
C:\[username]\odis would take some recoding. Maybe not that much
now that I think about it.

Couldn't you use the %UserProfile% environment variable? If you
paste %UserProfile% into START | RUN and hit OK, it should open the
user's profile folder, regardless of where it's located. Or you
might want %AppData% (though this may be on the C: drive instead of
on a server).

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

[David W. Fenton]

"Roald Oines" <r_*******@bresnan.net> wrote in
news:Wq********************@bresnan.com:

Tony Toews <tt****@telusplanet.net> wrote:
: "Roald Oines" <r_*******@bresnan.net> wrote:
:
<snip>
:
: Ouch. Yeah, you do have some interesting configuration issues.
: I'm not at all sure what the best answer is for you other than
: having to give all users permissions to the previously mentioned
: C:\DBs folder.
:
: Tony

Thanks -- I'm thinking that's the best solution. I know how to set
attributes in a batch file -- do you know if there's a way to
share a folder or set security options that way (I couldn't find
anything in help)? Otherwise I'll have to walk several,
not-very-computer-literate folks through that process over the
phone.

The real solution is to install your software and icons under the
All Users profile, but that seems to require administrative rights
to succeed. It would need to be run only once, though.

I hoped I might be able to find API code on the Access Web for
setting NT permissions or for invoking the RunAs service, but can't
find it there. This code:

http://www.mvps.org/access/api/api0054.htm

might help you with finding the various locations for the standard
Windows folders.

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

[Roald Oines]

David W. Fenton <dX********@bway.net.invalid> wrote:
: "Roald Oines" <r_*******@bresnan.net> wrote in
<snip>
::
:: Thanks -- I'm thinking that's the best solution. I know how to set
:: attributes in a batch file -- do you know if there's a way to
:: share a folder or set security options that way (I couldn't find
:: anything in help)? Otherwise I'll have to walk several,
:: not-very-computer-literate folks through that process over the
:: phone.
:
: The real solution is to install your software and icons under the
: All Users profile, but that seems to require administrative rights
: to succeed. It would need to be run only once, though.
:
: I hoped I might be able to find API code on the Access Web for
: setting NT permissions or for invoking the RunAs service, but can't
: find it there. This code:
:
: http://www.mvps.org/access/api/api0054.htm
:
: might help you with finding the various locations for the standard
: Windows folders.

Thanks. My company's default profile does apparently require Admin
rights to write to an All Users folder on an XP box, and as far as I
know, one of the centers I support has no Admins on site. I do know a
couple power users there who might be able to go around and edit the
permissions manually though...

--
Please remove the under_scores if replying by mail.

[Steve Jorgensen]

On Mon, 11 Oct 2004 20:53:20 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:W6********************@comcast.com:

Two thoughts:

One of the reasons we are granted Admin rights to our own PCs is
the installation of certain software, notably Microsoft
ActiveSync, for the Dell Axim PDAs, which use MS Windows Mobile.
This program must install a synchronization folder usually named
Pocket_PC_MyDocuments as a subfolder of MyDocuments. This
requires the user to be the installer, since file-synchronization
will not work correctly otherwise, and once installed, you cannot
move the MyDocuments folder without messing up synchronization,
nor can you move the Pocket_PC folder at all.

The user should have ownership of their own My Documents folder.
This is the whole reason that in Win2K the user profiles were moved
out of the Windows/WinNT folder, so that the OS's home folder could
have reduced access for end users.

There is simply no excuse for any software at all needing
administrative rights to install. It may be able to install itself
only for the user running it, but it should still be able to
successfully install itself.

And, once installed, no software should require anything above user
rights to run. Any software that requires it is software you should
stop using.

I disagree. I like the fact that, so long as I am running as a
non-administrative user, most software is not able to install. This means
it's harder for software to somehow install itself without my knowledge.
Software that installs with user rights would, still by definition, have
permission to read and modify any files belonging to me, since it was
installed under my account.

Of course, I'm savvy enough to know how to do a shift-right-click "Run As" to
run an installer as Administrator which is usually what I want, since if I do
want to install something on the computer, I'll want to be able to use it
under any login account.

[Darryl Kerkeslager]

My attention span in Networking Fundamentals was poor. I don't know the
answer. I'll have to play with these suggestions and find out.

Darryl Kerkeslager

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Couldn't you use the %UserProfile% environment variable? If you
paste %UserProfile% into START | RUN and hit OK, it should open the
user's profile folder, regardless of where it's located. Or you
might want %AppData% (though this may be on the C: drive instead of
on a server).

[Darryl Kerkeslager]

Thanks, David. I found Networking Fundamentals to be boring, and Windows
Administration was a non-required course. Who knew that I would actually
use the information ... sort of like Spanish, which I took 20 years ago.
Who knew then that Spanish would be so useful ...

Darryl Kerkeslager
"David W. Fenton" <dX********@bway.net.invalid> wrote:

Doesn't anyone learn even the barest basics of Windows
administration?

Logged in as an administrator, open Windows Explorer and browse to
the C:\ODIS folder.

Right click it and choose PROPERTIES, then SECURITY.

If the Users group has no setting already, add them and give them
full control of the folder.

Now, this only works if the folder already exists and you're
sittting at the PC and have an administrative logon available to
you. If you're having the user install programmatically, I don't
know how you'd do this. But the RunAs service exists precisely for
this purpose, to elevate privileges for the process involved so that
it can do things the user running it would otherwise be unable to
do.

[Darryl Kerkeslager]

"Tony Toews" <tt****@telusplanet.net> wrote:

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

Nevertheless, even if the performance does not take a

hit, in order for me to move the frontend, and the several subfolders, fromC:\odis to C:\[username]\odis would take some recoding. Maybe not that muchnow that I think about it.

Why would it take some recoding?

I hardcoded the folder names in various places. Laziness. Lecture me
tomorrow :)
Darryl Kerkeslager

[Darryl Kerkeslager]

"Steve Jorgensen" <no****@nospam.nospam> wrote:

Of course, I'm savvy enough to know how to do a shift-right-click "Run As" to run an installer as Administrator which is usually what I want, since if I do want to install something on the computer, I'll want to be able to use it
under any login account.

Rats. If I'd paid more attention in class, I'd know how to do that.

Thanks,
Darryl Kerkeslager

[David W. Fenton]

Steve Jorgensen <no****@nospam.nospam> wrote in
news:m8********************************@4ax.com:

On Mon, 11 Oct 2004 20:53:20 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:W6********************@comcast.com:

Two thoughts:

One of the reasons we are granted Admin rights to our own PCs is
the installation of certain software, notably Microsoft
ActiveSync, for the Dell Axim PDAs, which use MS Windows Mobile.
This program must install a synchronization folder usually named
Pocket_PC_MyDocuments as a subfolder of MyDocuments. This
requires the user to be the installer, since
file-synchronization will not work correctly otherwise, and once
installed, you cannot move the MyDocuments folder without
messing up synchronization, nor can you move the Pocket_PC
folder at all.
The user should have ownership of their own My Documents folder.
This is the whole reason that in Win2K the user profiles were
moved out of the Windows/WinNT folder, so that the OS's home
folder could have reduced access for end users.

There is simply no excuse for any software at all needing
administrative rights to install. It may be able to install itself
only for the user running it, but it should still be able to
successfully install itself.

And, once installed, no software should require anything above
user rights to run. Any software that requires it is software you
should stop using.

I disagree. I like the fact that, so long as I am running as a
non-administrative user, most software is not able to install.

Since software can be written to install only under a single user,
that means that THIS GETS YOU NO ADDITIONAL PROTECTION.
This means it's harder for software to somehow install itself
without my knowledge. Software that installs with user rights
would, still by definition, have permission to read and modify any
files belonging to me, since it was installed under my account.
And software that installs with administrative permission may very
well be able to modify EVERYTHING ON YOUR COMPUTER AND YOUR NETWORK.

No software should require access to components that the user can't
use.

Yes, rogue software could damage the user's filespace, but THAT'S
THE POINT -- that's the *only* thing it can damage, leaving the OS
and other software applications alone.
Of course, I'm savvy enough to know how to do a shift-right-click
"Run As" to run an installer as Administrator which is usually
what I want, since if I do want to install something on the
computer, I'll want to be able to use it under any login account.

When people bump up the privileges of their daily logon account to
administrative because they have to install software all the time,
then the result is that they are running as an administrator all the
time, "forced" to do so by all the software installations that are
improperly designed (that either must run as admin or that don't
utilize the RunAs facility).

The result is before us all -- a world of rampant trojan software
that hijacks PCs and pumps out spam and viruses to the rest of us.

In my experience, there is almost never a good reason for a software
installer to require admin permissions -- it almost always indicates
that the installer is based on outdated assumptions about where
shared libraries should go (in %WinDir%\System3d, for instance) or
is not using modern installer technology appropriately (i.e.,
utilizing the RunAs service when it's appropriate, such as with
device or printer drivers). And, of course, the RunAs service could
be used by a smart rogue installer to bump up its privileges.
Spoofing of the RunAs dialog could also be used by a rogue process
to collect admin usernames/passwords, so I keep the RunAs service
disabled on my own PC. Or, it indicates that the installer is trying
to muck around with things it has no business doing in the first
place.

I don't trust any installer that requires admin permission because I
don't know what it's doing to my system.

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

[Tony Toews]

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

Nevertheless, even if the performance does not take a

>hit, in order for me to move the frontend, and the several subfolders,from >C:\odis to C:\[username]\odis would take some recoding. Maybe not thatmuch >now that I think about it.

Why would it take some recoding?

I hardcoded the folder names in various places. Laziness. Lecture me
tomorrow :)

<chuckle> At the very least I'd suggest a global constant. And a Find & Replace
tool should quickly find all such occurances.

That said I prefer a GlobalOptions table.

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

[Steve Jorgensen]

On Tue, 12 Oct 2004 18:39:54 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

Steve Jorgensen <no****@nospam.nospam> wrote in
news:m8********************************@4ax.com :

On Mon, 11 Oct 2004 20:53:20 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:W6********************@comcast.com:

Two thoughts:

One of the reasons we are granted Admin rights to our own PCs is
the installation of certain software, notably Microsoft
ActiveSync, for the Dell Axim PDAs, which use MS Windows Mobile.
This program must install a synchronization folder usually named
Pocket_PC_MyDocuments as a subfolder of MyDocuments. This
requires the user to be the installer, since
file-synchronization will not work correctly otherwise, and once
installed, you cannot move the MyDocuments folder without
messing up synchronization, nor can you move the Pocket_PC
folder at all.

The user should have ownership of their own My Documents folder.
This is the whole reason that in Win2K the user profiles were
moved out of the Windows/WinNT folder, so that the OS's home
folder could have reduced access for end users.

There is simply no excuse for any software at all needing
administrative rights to install. It may be able to install itself
only for the user running it, but it should still be able to
successfully install itself.

And, once installed, no software should require anything above
user rights to run. Any software that requires it is software you
should stop using.

I disagree. I like the fact that, so long as I am running as a
non-administrative user, most software is not able to install.

Since software can be written to install only under a single user,
that means that THIS GETS YOU NO ADDITIONAL PROTECTION.

This means it's harder for software to somehow install itself
without my knowledge. Software that installs with user rights
would, still by definition, have permission to read and modify any
files belonging to me, since it was installed under my account.

And software that installs with administrative permission may very
well be able to modify EVERYTHING ON YOUR COMPUTER AND YOUR NETWORK.

No software should require access to components that the user can't
use.

Yes, rogue software could damage the user's filespace, but THAT'S
THE POINT -- that's the *only* thing it can damage, leaving the OS
and other software applications alone.

Of course, I'm savvy enough to know how to do a shift-right-click
"Run As" to run an installer as Administrator which is usually
what I want, since if I do want to install something on the
computer, I'll want to be able to use it under any login account.

When people bump up the privileges of their daily logon account to
administrative because they have to install software all the time,
then the result is that they are running as an administrator all the
time, "forced" to do so by all the software installations that are
improperly designed (that either must run as admin or that don't
utilize the RunAs facility).

The result is before us all -- a world of rampant trojan software
that hijacks PCs and pumps out spam and viruses to the rest of us.

In my experience, there is almost never a good reason for a software
installer to require admin permissions -- it almost always indicates
that the installer is based on outdated assumptions about where
shared libraries should go (in %WinDir%\System3d, for instance) or
is not using modern installer technology appropriately (i.e.,
utilizing the RunAs service when it's appropriate, such as with
device or printer drivers). And, of course, the RunAs service could
be used by a smart rogue installer to bump up its privileges.
Spoofing of the RunAs dialog could also be used by a rogue process
to collect admin usernames/passwords, so I keep the RunAs service
disabled on my own PC. Or, it indicates that the installer is trying
to muck around with things it has no business doing in the first
place.

I don't trust any installer that requires admin permission because I
don't know what it's doing to my system.

I see why we differ here. Of course, you're right that my practice doesn't
protect me at all from software that -is- willing to install as the local
user, but it offers a little protection from malevolent software that isn't
willing to do that. I also do not find that I spend much time operating as
Administrator so I can install software.

My standard practice is to simply avoid installing much software. There are a
few things I need, I make sure I trust them, then I install them for all
users. I use multiple user accounts on my machine for different things, and I
generally want the same tools available everywhere. If I really want a
sandboc (as I sometimes do), I like to use a real virtual machine.

[Darryl Kerkeslager]

Perhaps I don't understand all the finer points (well, okay, no perhaps),
but I don't quite understand how it is the software's fault. If I, as a
systems administrator, prohibit any software from installing without admin
rights, than that's how I want it, and the software be damned - is that
right?

Or as a systems administrator, do I only have the abilty to prohibit only
some installs, while other software is written so that it will install with
any rights - systems administrator be damned?
Darryl Kerkeslager

"David W. Fenton" <dX********@bway.net.invalid> wrote:

Since software can be written to install only under a single user,
that means that THIS GETS YOU NO ADDITIONAL PROTECTION.

And software that installs with administrative permission may very
well be able to modify EVERYTHING ON YOUR COMPUTER AND YOUR NETWORK.

When people bump up the privileges of their daily logon account to
administrative because they have to install software all the time,
then the result is that they are running as an administrator all the
time, "forced" to do so by all the software installations that are
improperly designed (that either must run as admin or that don't
utilize the RunAs facility).

In my experience, there is almost never a good reason for a software
installer to require admin permissions -- it almost always indicates
that the installer is based on outdated assumptions about where
shared libraries should go (in %WinDir%\System3d, for instance) or
is not using modern installer technology appropriately (i.e.,
utilizing the RunAs service when it's appropriate, such as with
device or printer drivers).

I don't trust any installer that requires admin permission because I
don't know what it's doing to my system.

[David W. Fenton]

"Darryl Kerkeslager" <Ke*********@comcast.net> wrote in
news:Mf********************@comcast.com:

Perhaps I don't understand all the finer points (well, okay, no
perhaps), but I don't quite understand how it is the software's
fault. If I, as a systems administrator, prohibit any software
from installing without admin rights, than that's how I want it,
and the software be damned - is that right?
So far as I know, there is no way on a Windows computer to prohibit
software from installing, period, unless you're willing to make the
computer mostly unusable.

An installer should not need access to system space to install
itself. If that rule is followed, it should install without issues
under a user logon.

Ever seen a prompt like this at the start of an installation?

Install this for all users, or just for the current user?

If you choose the former, you'll need minimal administrative rights
(e.g., putting shortcuts in the All Users profile), if you choose
the latter, it should not be an issue.
Or as a systems administrator, do I only have the abilty to
prohibit only some installs, while other software is written so
that it will install with any rights - systems administrator be
damned?

Prohibiting a user-level installer from installing would also mean
that the user probably can't edit their own files, or, at the very
least, can't save any user data in their own profile's Application
Data folders.

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