Robert Berke
asked on
Windows 7 uac virtualstore is not playing nicely with my front end database.
my logon script currently
copies \\server\frontEnd.mdb to c:\program files\myFrontEnds\*.*
copies \\server\frontEndShortCut. lnk to %ALLUSERSPROFILE%\desktop\ *.*
On XP this worked fine. The user clicks on frontEndShortCut.lnk and they get their own private copy of the front end.
On Windows 7 with user account control (uac) disabled, this also worked fine.
But, I decided to turn UAC on, and things have gotton messy.
When the user clicks on DesktopShortcut, the thing that actually gets opened is
C:\Users\rberke\AppData\Lo cal\Virtua lStore\Pro gram Files\myFrontEnds\frontend .mdb.
So, I am thinking of simply changing my logon script so
it copies \\server\frontEnd.mdb to c:\myFrontEnds\*.*
Does anybody think this is a bad idea? For instance with UAC enabled, how can I make the login script cannot run an MD c:\myfrontends and then assign user full control.
This is getting to be more complicated than I want.
Does anybody have a nice example of a login script that:
1. works under windows 7
2. works under xp
3. automatically installs a front end database without manual intervention.
4. does not require UAC to be diasabled
For instance, I previously ran into other problems (reported in https://www.experts-exchange.com/questions/26473654/batch-file-not-working-with-run-as-administrator.html)
copies \\server\frontEnd.mdb to c:\program files\myFrontEnds\*.*
copies \\server\frontEndShortCut.
On XP this worked fine. The user clicks on frontEndShortCut.lnk and they get their own private copy of the front end.
On Windows 7 with user account control (uac) disabled, this also worked fine.
But, I decided to turn UAC on, and things have gotton messy.
When the user clicks on DesktopShortcut, the thing that actually gets opened is
C:\Users\rberke\AppData\Lo
So, I am thinking of simply changing my logon script so
it copies \\server\frontEnd.mdb to c:\myFrontEnds\*.*
Does anybody think this is a bad idea? For instance with UAC enabled, how can I make the login script cannot run an MD c:\myfrontends and then assign user full control.
This is getting to be more complicated than I want.
Does anybody have a nice example of a login script that:
1. works under windows 7
2. works under xp
3. automatically installs a front end database without manual intervention.
4. does not require UAC to be diasabled
For instance, I previously ran into other problems (reported in https://www.experts-exchange.com/questions/26473654/batch-file-not-working-with-run-as-administrator.html)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I moved it up to c:\myFrontEnds, and my folder security problems went away. (I don't know why lsmConsulting thought they wouldn't, he is usually gives good advice.)
There is another UAC problem causing the net time %logonserver% /set /yes to give an access denied, but that is not a big deal.
There is another UAC problem causing the net time %logonserver% /set /yes to give an access denied, but that is not a big deal.
Thank you, and thanks for the update. Good luck going forward. ... Thinkpads_User
Root drives are protected in Vista and Win7, but of course you can change permissions/restrictions as needed.
Proper application deployment techniques in Vista forward suggest that you install Programs to the Program Files section (this is a WRITE ONLY section) and that you install Data files to one of the Data folders (depending on how much access is needed, and by whom). If your FE needs to write to local tables, or you store data directly in the FE, then you'll need to move it to the Data folders section.
You can store your apps on the root drive, but don't be surprised when a Win7 update comes out and breaks this. UAC is not going away, and it's only going to get more restrictive. The root drive was NEVER intended as a storage location for user-run programs. That's what Program Files are for (or the Data folders, depending).
Proper application deployment techniques in Vista forward suggest that you install Programs to the Program Files section (this is a WRITE ONLY section) and that you install Data files to one of the Data folders (depending on how much access is needed, and by whom). If your FE needs to write to local tables, or you store data directly in the FE, then you'll need to move it to the Data folders section.
You can store your apps on the root drive, but don't be surprised when a Win7 update comes out and breaks this. UAC is not going away, and it's only going to get more restrictive. The root drive was NEVER intended as a storage location for user-run programs. That's what Program Files are for (or the Data folders, depending).
ASKER
LSMConsulting:
As far as I know MS Access always opens MDBs for update, even if they don't modify their own tables.
I have opened up another question to deal with this subject specifically.
If you want some points, we can continue the discussion here.
https://www.experts-exchange.com/questions/26489270/NEVER-put-FrontEnd-mdb-file-into-c-program-files-if-UAC-is-turned-on-in-Windows-7.html
As far as I know MS Access always opens MDBs for update, even if they don't modify their own tables.
I have opened up another question to deal with this subject specifically.
If you want some points, we can continue the discussion here.
https://www.experts-exchange.com/questions/26489270/NEVER-put-FrontEnd-mdb-file-into-c-program-files-if-UAC-is-turned-on-in-Windows-7.html
<As far as I know MS Access always opens MDBs for update, even if they don't modify their own tables.>
I'm not aware of this, but you may be correct. The issue occurs when you actually attempt to WRITE the file - merely being able to do so shouldn't trigger any isuses.
I'm not aware of this, but you may be correct. The issue occurs when you actually attempt to WRITE the file - merely being able to do so shouldn't trigger any isuses.
This is for Vista, but the same caveats apply to Win7:
http://msdn.microsoft.com/en-us/library/bb530410.aspx