SHaring a MS access frontend amongst all TS users

[Jason Woodbury]

I have an Acess front end I am trying to share with all users. I would like
to know if there is a way for TS or scripting wise to implement 1 access
front end and have it make a copy from a set location to every users desktop
everytime they login. I am tired of having to delete every single users
front end everytime it updates(which it seems to do frequently). As it
stands, I have 1 copy of the front end on everyones desktop, I would like for
them to be able to access a master copy and the server to automatically
download a fresh copy everytime they login and delete it when they logout.
Is there a way to go about this so I can simply be able to update a master
access frontend and then everyone will have the updated version everytime
they login?

 

[TP]

Hi,

You can do this in their logon script. A very basic technique
would be this:

1. Create a .cmd file with the following contents, substituting
the full path and file name to your central copy of the front end
for <frontendfull>:

copy "<frontendfull>" %temp%

Note that the quotes should stay.

2. Run the above file while logged on via TS as an admin.

3. Create a new shortcut on the All Users desktop with the
target set to %temp%\<frontendcopy> Substitute the file name
*only* of your frontend for <frontendcopy>

With the above .cmd file called from the user's logon script,
the front end file will be copied automatically each time a
user logs on and then deleted when they log off. You should
set idle and disconnected timeouts so that even users that
forget to logoff/don't logoff will get a fresh copy.

The above is just one example--you could get much fancier
if you like.

-TP

Jason Woodbury wrote:
> I have an Acess front end I am trying to share with all users. I
> would like to know if there is a way for TS or scripting wise to
> implement 1 access front end and have it make a copy from a set
> location to every users desktop everytime they login. I am tired of
> having to delete every single users front end everytime it
> updates(which it seems to do frequently). As it stands, I have 1
> copy of the front end on everyones desktop, I would like for them to
> be able to access a master copy and the server to automatically
> download a fresh copy everytime they login and delete it when they
> logout. Is there a way to go about this so I can simply be able to
> update a master access frontend and then everyone will have the
> updated version everytime they login?

 

[Jason Woodbury]

I will give this a shot, thank you in advance

"TP" wrote:

> Hi,
>
> You can do this in their logon script. A very basic technique
> would be this:
>
> 1. Create a .cmd file with the following contents, substituting
> the full path and file name to your central copy of the front end
> for <frontendfull>:
>
> copy "<frontendfull>" %temp%
>
> Note that the quotes should stay.
>
> 2. Run the above file while logged on via TS as an admin.
>
> 3. Create a new shortcut on the All Users desktop with the
> target set to %temp%\<frontendcopy> Substitute the file name
> *only* of your frontend for <frontendcopy>
>
> With the above .cmd file called from the user's logon script,
> the front end file will be copied automatically each time a
> user logs on and then deleted when they log off. You should
> set idle and disconnected timeouts so that even users that
> forget to logoff/don't logoff will get a fresh copy.
>
> The above is just one example--you could get much fancier
> if you like.
>
> -TP
>

 

[Jason Woodbury]

TP, that works perfectly other than now, how do I go about setting up a
seperate login script just for that? I tried via group policy yet it seems
not to run, even after adding it to allowed programs to run. Doing it via
regular profile worked great, until I tested it with a user and it tries to
do the same locally on their machine. I can't have that because these are
outside offices and talk about a slow connection back and forth. I need to
figure out a way to have this run only on the TS clients and not on their
local PC's. Any advice you might have would be helpful, not a scripter by
any means so please take that into account as well.

"TP" wrote:

> Hi,
>
> You can do this in their logon script. A very basic technique
> would be this:
>
> 1. Create a .cmd file with the following contents, substituting
> the full path and file name to your central copy of the front end
> for <frontendfull>:
>
> copy "<frontendfull>" %temp%
>
> Note that the quotes should stay.
>
> 2. Run the above file while logged on via TS as an admin.
>
> 3. Create a new shortcut on the All Users desktop with the
> target set to %temp%\<frontendcopy> Substitute the file name
> *only* of your frontend for <frontendcopy>
>
> With the above .cmd file called from the user's logon script,
> the front end file will be copied automatically each time a
> user logs on and then deleted when they log off. You should
> set idle and disconnected timeouts so that even users that
> forget to logoff/don't logoff will get a fresh copy.
>
> The above is just one example--you could get much fancier
> if you like.
>
> -TP
>
> Jason Woodbury wrote:
> > I have an Acess front end I am trying to share with all users. I
> > would like to know if there is a way for TS or scripting wise to
> > implement 1 access front end and have it make a copy from a set
> > location to every users desktop everytime they login. I am tired of
> > having to delete every single users front end everytime it
> > updates(which it seems to do frequently). As it stands, I have 1
> > copy of the front end on everyones desktop, I would like for them to
> > be able to access a master copy and the server to automatically
> > download a fresh copy everytime they login and delete it when they
> > logout. Is there a way to go about this so I can simply be able to
> > update a master access frontend and then everyone will have the
> > updated version everytime they login?
>

 

[TP]

Hi,

As with most things there are multiple ways to handle this,
here are some:

1. You could create an OU for your TS server and move it
into it, then create a GPO with loopback enabled, replace
mode. You would set the security so that the GPO would
*not* apply to administrators (Add a Deny Apply Group
Policy entry to the GPO's DACL for the Administrators
group).

With this option the GPO settings would only apply when
the users logon to the TS and not when they logon to their
normal workstations.

2. Place the copy file command in the usrlogon.cmd script
on the TS instead of in a regular user logon script. This only
runs when a user logs on to the TS.

3. In the logon script you created, use an IF statement to
check the computername and if it does not equal the TS
server's name, then skip the copy file step.

Option 1 will give you lots of flexibility and is a common
configuration for terminal servers. You can use it to set other
restrictions such as limiting start menu items, etc.

Loopback processing of Group Policy

http://support.microsoft.com/kb/231287

-TP

Jason Woodbury wrote:
> TP, that works perfectly other than now, how do I go about setting up
> a seperate login script just for that? I tried via group policy yet
> it seems not to run, even after adding it to allowed programs to run.
> Doing it via regular profile worked great, until I tested it with a
> user and it tries to do the same locally on their machine. I can't
> have that because these are outside offices and talk about a slow
> connection back and forth. I need to figure out a way to have this
> run only on the TS clients and not on their local PC's. Any advice
> you might have would be helpful, not a scripter by any means so
> please take that into account as well.

 

[Jason Woodbury]

Already had the loopback policy and such as you explained, with a GPO telling
what users can and can't have and the policy does not reflect on admins. Now
the usrlogon.cmd, how do I get that to load during bootup for regular users?
Do i place that usrlogon.cmd file in the scripts to run in the login scripts
via GPO? I added the copy command to the bottom right before the :cont but
doesn't work automatically.

"TP" wrote:

> Hi,
>
> As with most things there are multiple ways to handle this,
> here are some:
>
> 1. You could create an OU for your TS server and move it
> into it, then create a GPO with loopback enabled, replace
> mode. You would set the security so that the GPO would
> *not* apply to administrators (Add a Deny Apply Group
> Policy entry to the GPO's DACL for the Administrators
> group).
>
> With this option the GPO settings would only apply when
> the users logon to the TS and not when they logon to their
> normal workstations.
>
> 2. Place the copy file command in the usrlogon.cmd script
> on the TS instead of in a regular user logon script. This only
> runs when a user logs on to the TS.
>
> 3. In the logon script you created, use an IF statement to
> check the computername and if it does not equal the TS
> server's name, then skip the copy file step.
>
> Option 1 will give you lots of flexibility and is a common
> configuration for terminal servers. You can use it to set other
> restrictions such as limiting start menu items, etc.
>
> Loopback processing of Group Policy
>
> http://support.microsoft.com/kb/231287
>
> -TP
>
> Jason Woodbury wrote:
> > TP, that works perfectly other than now, how do I go about setting up
> > a seperate login script just for that? I tried via group policy yet
> > it seems not to run, even after adding it to allowed programs to run.
> > Doing it via regular profile worked great, until I tested it with a
> > user and it tries to do the same locally on their machine. I can't
> > have that because these are outside offices and talk about a slow
> > connection back and forth. I need to figure out a way to have this
> > run only on the TS clients and not on their local PC's. Any advice
> > you might have would be helpful, not a scripter by any means so
> > please take that into account as well.
>

 

[TP]

Hi,

I meant for you to choose *only* one of the three options
I presented. If you have loopback set then the GPO
policies should not be running when the users logon to
their workstations. Are the users located in a different OU
than the TS? They should be.

Is your TS a DC?

If using the usrlogon.cmd option, place your line below the
:Cont1 line. Usrlogon runs automatically.

-TP

Jason Woodbury wrote:
> Already had the loopback policy and such as you explained, with a GPO
> telling what users can and can't have and the policy does not reflect
> on admins. Now the usrlogon.cmd, how do I get that to load during
> bootup for regular users? Do i place that usrlogon.cmd file in the
> scripts to run in the login scripts via GPO? I added the copy
> command to the bottom right before the :cont but doesn't work
> automatically.

 

[Jason Woodbury]

It is a DC and i changed the command you had me create to go after the
:cont. These users are on a seperate OU called TSUsers and everything in the
GPO only relates to these users in the OU. Sorry for al the confusion and i
do appreacite the help and your time.
"TP" wrote:

> Hi,
>
> I meant for you to choose *only* one of the three options
> I presented. If you have loopback set then the GPO
> policies should not be running when the users logon to
> their workstations. Are the users located in a different OU
> than the TS? They should be.
>
> Is your TS a DC?
>
> If using the usrlogon.cmd option, place your line below the
> :Cont1 line. Usrlogon runs automatically.
>
> -TP
>
> Jason Woodbury wrote:
> > Already had the loopback policy and such as you explained, with a GPO
> > telling what users can and can't have and the policy does not reflect
> > on admins. Now the usrlogon.cmd, how do I get that to load during
> > bootup for regular users? Do i place that usrlogon.cmd file in the
> > scripts to run in the login scripts via GPO? I added the copy
> > command to the bottom right before the :cont but doesn't work
> > automatically.
>

 

[TP]

You have it working okay now using the usrlogon?

The GPO I was referring to is the one that applies to the
OU that the TS is located in--in this case the Default Domain
Controllers Policy.

If you are satisfied with the results using the usrlogon then
I would just leave things alone.

-TP

Jason Woodbury wrote:
> It is a DC and i changed the command you had me create to go after the
>> cont. These users are on a seperate OU called TSUsers and
>> everything in the
> GPO only relates to these users in the OU. Sorry for al the
> confusion and i do appreacite the help and your time.

 

[Jason Woodbury]

Guess what I am asking is should i put the usrlogon.cmd into the
sysvol\blah\blah\scripts and choose it from there on the TSUser OU? Should i
make it a logon script in the AD under the scripts folder on sysvol?

"TP" wrote:

> You have it working okay now using the usrlogon?
>
> The GPO I was referring to is the one that applies to the
> OU that the TS is located in--in this case the Default Domain
> Controllers Policy.
>
> If you are satisfied with the results using the usrlogon then
> I would just leave things alone.
>
> -TP
>
> Jason Woodbury wrote:
> > It is a DC and i changed the command you had me create to go after the
> >> cont. These users are on a seperate OU called TSUsers and
> >> everything in the
> > GPO only relates to these users in the OU. Sorry for al the
> > confusion and i do appreacite the help and your time.
>

 

[Jason Woodbury]

here is a copy of the usrlogon.cmd
@Echo Off

Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"
If "%_SETPATHS%" == "FAIL" Goto Done

Rem
Rem This is for those scripts that don't need the RootDrive.
Rem

If Not Exist "%SystemRoot%\System32\Usrlogn1.cmd" Goto cont0
Cd /d "%SystemRoot%\Application Compatibility Scripts\Logon"
Call "%SystemRoot%\System32\Usrlogn1.cmd"

:cont0

Rem
Rem Determine the user's home directory drive letter. If this isn't
Rem set, exit.
Rem

Cd /d %SystemRoot%\"Application Compatibility Scripts"
Call RootDrv.Cmd
If "A%RootDrive%A" == "AA" End.Cmd

Rem
Rem Map the User's Home Directory to a Drive Letter
Rem

Net Use %RootDrive% /D >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
if ERRORLEVEL 1 goto SubstErr
goto AfterSubst
:SubstErr
Subst %RootDrive% /d >NUL: 2>&1
Subst %RootDrive% "%HomeDrive%%HomePath%"
:AfterSubst

Rem
Rem Invoke each Application Script. Application Scripts are automatically
Rem added to UsrLogn2.Cmd when the Installation script is run.
Rem

If Not Exist %SystemRoot%\System32\UsrLogn2.Cmd Goto Cont1

Cd Logon
Call %SystemRoot%\System32\UsrLogn2.Cmd


:Cont1
copy "D:\TW\tw.mde" %temp%

one



You can see at the end my command you gave me. I don't know how to do "IF"
statements so any help would be appreciated and then I need to know exactly
where this needs to go in order for users to reflect it. I was thinking on
their normal profile under AD, and then it will see the "IF" statement and
then just run normally until they login to TS. Am I right in this?

"Jason Woodbury" wrote:

> Guess what I am asking is should i put the usrlogon.cmd into the
> sysvol\blah\blah\scripts and choose it from there on the TSUser OU? Should i
> make it a logon script in the AD under the scripts folder on sysvol?
>
> "TP" wrote:
>
> > You have it working okay now using the usrlogon?
> >
> > The GPO I was referring to is the one that applies to the
> > OU that the TS is located in--in this case the Default Domain
> > Controllers Policy.
> >
> > If you are satisfied with the results using the usrlogon then
> > I would just leave things alone.
> >
> > -TP
> >
> > Jason Woodbury wrote:
> > > It is a DC and i changed the command you had me create to go after the
> > >> cont. These users are on a seperate OU called TSUsers and
> > >> everything in the
> > > GPO only relates to these users in the OU. Sorry for al the
> > > confusion and i do appreacite the help and your time.
> >

 

[TP]

You don't need to do anything other than edit the file on
the server's c: drive.

Do you have Terminal Server installed? You can check by
opening Terminal Services Configuration (tscc.msc), clicking
on Server Settings on the left, and then examining the License
Mode on the right. It should say either Per Device or Per
User.

Alternatively you can look in Add/Remove Windows
Components to see if Terminal Server is checked.

-TP

Jason Woodbury wrote:
> Guess what I am asking is should i put the usrlogon.cmd into the
> sysvol\blah\blah\scripts and choose it from there on the TSUser OU?
> Should i make it a logon script in the AD under the scripts folder on
> sysvol?

 

[Vera Noest [MVP]]

Maybe usrlogon.cmd never gets to the :Cont1 label, because
SetPaths.Cmd fails?

Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"
If "%_SETPATHS%" == "FAIL" Goto Done

_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
TS troubleshooting: http://ts.veranoest.net
___ please respond in newsgroup, NOT by private email ___


"TP" wrote on 01 aug 2007:
>
> If using the usrlogon.cmd option, place your line below the
>:Cont1 line. Usrlogon runs automatically.
>
> -TP
>
> Jason Woodbury wrote:
>> I added the copy command to the bottom right before
>> the :cont but doesn't work automatically.

 

[TP]

That is a good point I didn't consider. It could be failing and thus
not running the copy. In my experience I have not had that fail
so unless there is something strange going on my first guess
would be it is working. If the script was unable to get the
common paths there would likely be other problems
manifesting with applications because that is something lots
of programs do.

Jason, can you test this by moving the code to the end of
the file, after one?

I am concerned that usrlogon is not running at all like if the
server is in remote administration mode. That is why I was
asking him about the licensing mode.

Jason, can you test that usrlogon is actually running by placing a
pause at the top of the usrlogon.cmd file? If it is running this
will cause it to stop during logon so that you can click on
the command window and press a key to continue.

Thanks.

-TP

Vera Noest [MVP] wrote:
> Maybe usrlogon.cmd never gets to the :Cont1 label, because
> SetPaths.Cmd fails?
>
> Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"
> If "%_SETPATHS%" == "FAIL" Goto Done
>
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> TS troubleshooting: http://ts.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___

 

[Jason Woodbury]

found an easier way to do it actually, just added it to the registry key
alongside the usrlogon.cmd, worked like a charm. I don't really worry too
much about the admins getting a file in the temp drive everytime they login,
sometimes we need to use it as well.
thank you guys for all the help


"Vera Noest [MVP]" wrote:

> Maybe usrlogon.cmd never gets to the :Cont1 label, because
> SetPaths.Cmd fails?
>
> Call "%SystemRoot%\Application Compatibility Scripts\SetPaths.Cmd"
> If "%_SETPATHS%" == "FAIL" Goto Done
>
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> TS troubleshooting: http://ts.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
>
>
> "TP" wrote on 01 aug 2007:
> >
> > If using the usrlogon.cmd option, place your line below the
> >:Cont1 line. Usrlogon runs automatically.
> >
> > -TP
> >
> > Jason Woodbury wrote:
> >> I added the copy command to the bottom right before
> >> the :cont but doesn't work automatically.
>

 

[TP]

I'm glad you found a solution that works for you!

Thanks for posting back.

-TP