Setting up Access for use with Terminal Services

  • Thread starter Thread starter kiln
  • Start date Start date
K

kiln

Could someone explain step by step the best way to set up an Access 2000
app on a Windows 2003 TS server? There are a couple of threads on this
but nothing very explict.

The backend will be on another Windows 2003 server. There is a skilled
network admin on hand, that's not my realm. The database is split into
front/back ends. There is a front end updating routine in use for the
LAN workstations that should work for these TS installs.

For short term use, I'm going to ask the network admin to install Office
2000 on the TS machine. All of the WAN users already have licensed
copies of Access. Medium term this app will be deployed as a runtime,
but I don't want to grapple with those additional issues right now.

I've read that each TS user of the app should have a special folder
created for them that will host the Access front end. Makes sense...but
where do you typically place that folder? In each login's Docs and
Settings hive? Or create a special set of folder on c: for these user
folders? I never run apps out of the my docs area but I suppose that it
could make sense.

What other issues are there that I'd likely run into?
 
Hi,
Not sure about Windows Server 2003 But we did a project where we have a
Access XP application installed on a Windows 2000 Terminal Server and it
works awesome
All users have home drives that are mapped to H:\
In there is their Front End. So yes everyone gets their own FE
In our case we had a SQL Server backend but I am sure you just put the BE in
a common location

I remember there was some special thing that had to be done to get Office
2000 to install on A Terminal Server (I think it had to do with the early
version of MSI that was used with Office 2000) My suggestion would be
upgrade to Access XP way better and far fewer issues.

Not sure what else to say but to our application is a core business system
being used by users across the country and works a treat over Terminal
Server. We have never come across Terminal Server issues, ever

Regards
Bruce
 
Thank you for that information. Tell me, what are the home drives about?
H: is a mapped drive but where is the actual share located? I'm not sure
what that is about. Did you mean home directory?
 
Yeah, Drive, Directory, Folder depends what era you stated in this business
So the Home folders would be in a structure sort of like this

D:\Users
\ Bob
\ Sue
\Mike
(D: being the data drive on your server) if your Server is not set up with a
system Drive (C:) and a data Drive (D:) then get another System Admin!

Then these folders are shared as hidden shares e.g. D:\Users\ Bob is shared
as Bob$ and the Domain Admin has full control rights and the Users (in this
case Bob) has Change rights
Then in Bob's profile he has his Home directory mapped to this share.
The result is when he logs in her will now see a H: Drive in his my computer
Windows explorer

This is all basic Windows Server stuff that you System Admin should know and
do for you

Let me know if you have any further questions
Bruce
 
It really helps a lot if they have people who understand
TS/Citrix. You need to have someone who understands stuff
like setting up local printers for the Citrix clients.

(david)
 
Thanks, again very helpful. The network admin is very good but isn't
tuned in to Access db names, so I'm checking out that part.

The db backend will be used by both remote user via TS and local LAN
folks. My first instinct was to put the backend on the TS machine, on
the 2nd hdd, in order to reduce connections to it over the network (less
oppty for corruption). The local users would still of course connect
over the LAN. I think the network admin prefers keeping the backend on
the other win2003 server, the one that hosts exchange and all of that.
Is there any reason NOT to put the db backend on the TS server as far as
your experience goes? Don't expect it'd have any apparent impact on
responsiveness as I think the TS connection will invoke more lag than
the speed of the connection to the backend.

The home directory thing sounds great, I've read about it, and this does
seem to solve some things.
 
Yes put the BE on the Terminal Server. Keep the LAN traffic down to a
minimum
The response time for the TS users will be better and it is no different for
the LAN users
If the server has the horsepower then put it there and it is good to keep it
away from Exchange as well

Bruce
 
I am curious if you were able to get this to work? We have a similar
situation where we have a TS 2003 Cluster running into a Server 2003
infrastructure. Our Access Database is Access 2000. There is a Tech Note
regarding needing to run the Terminal Services Transform on an Access 2000
database; however, this relates to a Server 2000 environment. I am not able
to find any information on what should be done in a Server 2003 environment.
I am courious abour what you were able to get working?
 
The problem was solved by placing the Transform file in the correct
directory. The following set-up were used to resolve our problem.

1) Open the 'Add/Remove Programs' application and remove the 'Microsoft
Access 2000 Runtime' if it is listed.
2) Unzip the ART.zip file to a location on the Terminal Server. This path
should be noted for the subsequent steps.
3) Create a following folder: “C:\Program
Files\ORKTools\Toolbox\Tools\Terminal Server Toolsâ€. Copy the transform file
called Termsrvr_ART.mst to this folder.
4) From the command line type in the following command, where <> denotes the
path from step 2: "<>\art\setup.exe" transforms=“C:\Program
Files\ORKTools\Toolbox\Tools\Terminal Server Tools\Termsrvr_art.mstâ€
 
Robert1105 said:
The problem was solved by placing the Transform file in the correct
directory. The following set-up were used to resolve our problem.
Click to expand...

Thanks for posting your resolution. I've saved your posting for
future reference.

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
 
Back
Top