Installing Adobe Acrobat Pro On Terminal Server
Lorean Hoefert
A fellow employee requires Adobe Acrobat Pro to be installed for their use, and my management would like me to have this sorted out. The employee uses a thin client to connect to a terminal server for all of their administration work.
the licensing for terminal server is considered as the normal licensing process, which means they need to buy that many number of licenses for Acrobat for which the number of users will be accessing the terminal server (like citrix) to access the software. For eg if 10 users are accessing the citrix server at particular time to use the Acrobat software then they need 10 licenses for the same.
I would just like to know if anyone has any experience dealing with Adobe Reader DC crashing on a terminal / RDP server that is used by approx 20-30 people at a time. We have a bespoke program that generates reports to it and it has recently started crashing when it does so. It seems to make the report, and be happy for a few seconds, and then stop working. Or it will be happy until they try to print or save it.
I have seen this happen over the years for multiple regular PCs and also terminal server environments, the whole acrord32.exe process just hangs up and even after terminating it won't restart or open for ANYONE after that ... FYI - best way to do the cleanup is set up a script to forcefully term ALL acrord32.exe processes AND then clean out the prefetch folder of the acrord32 prefetch file, after that, it might also need a reboot after that. That's helped ... but acrord32.exe isn't always computer friendly at the best of times. Often it happens either when there is an update available, or it autoupdated and the exe is a new 'version' compared to what Windows holds in the prefetch, then you have issues.
So far I've only really used normal servers and clients, but now customers ask about terminal Server, and I'd like to know pro's and con's of using them instead of an "old-fashioned" client-server network.
We used both environments (we're a public school system), and when I started here we were running several terminal servers for teachers and students, and now we're fat clients and role-specific servers (no terminal servers for users).
"Instant" troubleshooting. We were able to check a user's session easily and quickly when a call came in. Yes, remote desktop software can do this (and we use it). But on the terminal servers, you have a small pool of machines, not a desktop that was tweaked or altered with XYZ programs that you didn't know where changed by another tech or it was changed and the records are lost or never kept. Tight adherence to policies and record keeping can do this. Reality is, at least in public school systems I know of, this isn't followed very often.
Cons? You have twenty users on a system. System reboots, dies, hardware issue,...twenty users, kicked offline, instantly. And users don't understand terminals to begin with. They don't care why something's weird. They just know something isn't working. One switch goes wonky or one server goes wonky and you've taken out a large number of users.
Printer drivers acted strange at times. Interaction among software increases the chance of "glitches". Especially with terminal servers...they always seemed more sensitive to it. But maybe I'm being paranoid. Remember one server affecting everyone? Well, one bad software install can cause headaches for everyone...and bit rot was a constant cause for edginess as drivers were updated or configuration changes were made.
Overall terminal services are cheaper, despite the CALs necessary for licensing. Your systems scattered around are cheaper, you can manage more users with fewer people, and you invest in your servers and network infrastructure, not necessarily giving the CEO a $2,000 machine for doing his email. But they're only cheaper if you're running in an environment that is suited for terminal services.
We had to move because over time we were getting more and more people that HAD to have something they wanted installed but other people didn't, and for licensing it could only be used by a small group of people. Or the software was made with Macromedia Director (ugh) and didn't "quite" work right (refresh was "off" with graphics, animations were choppy...). Or we had people running software that was just bloated and bogged down servers. Or we had people that had to use CD's for a presentation or material and they couldn't access them via the terminals (again, may have improved). Eventually we were putting in special workstations for certain tasks (log in once to run Photoshop, use the terminal shortcut to get to Office...) and finally it was too much of a burden to dual-support having labs that ran XYZ and terminals to support ABC. We had too many diverse needs.
One example would be trying to run an Access database form from a file share that's not locally replicated. Switching to a central terminal server environment in that case will boost application performance as it is then running on a central very high-performance terminal server, with a high-capacity and low-latency connection to the application server or resource. Many older line-of-business applications built with similar technology will respond much quicker if the client-side part is running close to the server-side.
And as long as the load isn't sustained and ruining the experience for other users, a number of older applications can actually respond a lot faster to the end-users not only due to lower latency to resources but because there's room for more burst performance in a high-speed server (obviously screen refresh may not be fluid, but fluid animation and quick result on say a customer search form are two very different things). Almost like Chopper said, going TS is sometimes an easy way to fix old stuff. There are other ways to do it like replicating file resources, using branch cache functionality and switching to web applications - or even siloing individual applications which would gain from this into terminal servers, serving them on fat clients as a seamless application.
Serving terminal server sessions to users on the road can also provide performance boosts. Trying to use a laptop and VPN while on a train using mobile broadband to access a shared Access form or line-of-business client-server-app with always-online-requirement on a central server will most likely be infuriatingly slow and unreliable. Replace it with a terminal session and it will probably be very zippy as long as the connection doesn't die completely. And if it does die, the session state will be preserved when resuming the connection (as long as the set parameters for auto-logoff aren't met) and the user can continue his or her work where it was left.
There is another way. Using an admin command prompt, copy the font file(s) to the "c:\windows\fonts" folder. Then edit the registry to add the font file name to the list in (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts) Reboot the machine. I have used this to install a bar code font on our terminal server for our warehouse users.
Adobe is looking for the version folder under local appdata.
Using folder redirection and roaming profiles in a terminalserver environment, appdata\local is usually excluded. But some applications still like to put some required data here, to give IT some headaches.
Note. If ABBYY Screenshot Reader is installed on a terminal server and accessed via Windows RemoteApp or Citrix Workspace App, users will only be able to make screenshots in applications that are running on the terminal server.
IT provides a terminal server for Faculty/Staff to use for emergencies and away from campus activities. Below are the instructions for connecting to our REMOTE system. Please test all software prior to leaving campus and before an emergency.
If you have both the full Adobe Acrobat and Acrobat Reader installed on the server, select which one will be the default. Since you will be installing the customized Acrobat Reader, the options in Run Installation and If reboot required at the end of installation can be ignored.
I have a headless VM (running Ubuntu server 17.04) that I use SSH to access. I'm comfortable with the basics of X11 forwarding, and I can forward xterm and friends just fine. XFCE terminal also forwards OK.
On the local machine, install the VNC client (yum install -y tigervnc) You can add "exec /usr/bin/gnome-terminal" to your /.vnc/xstartup file. then run: ssh -L 5903:localhost:5903 -N -f -l user remote-server-IP-or-hostnameThe port number here will be 59 and the port number you chose
This can be automated by calling "%LOCALAPPDATA%\slack\Update.exe" --uninstall -s in the users context, e.g. during the logon script. If your machine hosts multiple users (e.g. a terminal server), then we recommend our machine-wide MSI which would uninstall Slack for all users automatically.
This guide assumes you have used the "Server - Install New Server" SOP to physically install the new server and add to domain. Do not make the terminal server a domain controller or transfer FSMO roles to it as it is not secure to do so.
Before installing the RDS role, you can install any software using the normal route. After you install the RDS role, the server must be put into install mode before installing if the software needs to work with RDS.
Step 1. Ensure that SSH is enabled on the router that you use as terminal server. In the configuration example, local database is used for authentication. Radius or TACACS authentication method can also be used.
In this example, 1.1.1.1 is the loopback address of terminal server. To come back to terminal server, you need to use Ctrl + Shift + 6, release the buttons and instantly press X.
Step 9. You won't see any change in the menu untilyou apply it. So, apply it to the vty lines so that, when user opens a remote session to the terminal server, it gives the menu prompt.
When connected to a terminal server session, programs run on the terminal server. Windows Remote Desktop sends your keystrokes and mouse movements to the terminal server and displays the screen image sent back from the terminal server.
e2b47a7662