Hi DeniseB and Mike Cook sorry to hear about this, I look after a number of Sage 300 RDS sites, some quite large, and have experienced and resolved this issue.  Its normally a problem with the "Follow Me Print" or "RDS Redirect" print driver, or a very bandwidth intensive print driver like PostScript.  Remember when using RDS's redirection options the job has to be spooled to the local machine in a generic format, converted, then printed seperately on the local print driver which is really inefficient.  To solve the slow print issue I would recommend trying the following:

1. Install local copies of printer drivers onto the RDS server itself, ensuring the RDS server can print directly to said printers in the office.  Then ensure the default printer set for users is the actual office printer they use installed directly on the RDS and NOT a redirected or "follow me" printer.  You can disable printer redirection on your published RemoteApp session collection or if using traditional desktop login to launch Sage, on the RDP connection icon users access.
2. If users are accessing Sage from non-domain joined computers at home or in branch offices where there is no WAN/LAN connection then you will need to continue using Printer Redirection.  In this case, encourage users to set an efficient local default driver for their printers like PCL6 instead of PostScript to significantly reduce bandwidth needs.  Particularly invoices with graphics are going to sending hundreds of megabytes per page through inefficient redirection.
3. Non-commercial printer drivers are problematic.  In recent years, due to high speed USB a lot of home/home office printers have very lazy generic drivers that when printing graphics just push gigabytes of bitmapped raster data down the USB cable to the printer with no on-board printer RAM - everything is soft managed on the computer itself.  This would have crashed PC's 20 years ago but is no issue now.  When using these printers over redirection and graphics are involved the network consequences, especially for users on Wifi or internet connections and not gigabit+ LAN can be horrific.  In this case try to see if the default printer these users have can be switched to a network friendly print driver.
4. Print spooler bugs - particularly when using older versions of Office there is a horrible bug with the virtual OneNote printer where when a user on the RDS accidentally has OneNote printer as their default printer and they send a job to it, the print spooler starts bleeding memory and CPU slowing everything down.  Try to remove any installed or redirected OneNote printers and ensure all users have their correct printers set as the default printer.
5. Avoid using the option to "Allow Windows to Manage my default printer" - always ensure users hard-set their correct printer on their RDS windows profile.

I know this advice is pretty random but I've encountered these issues in the wild so I hope one of these helps.  Let me know how you go and if we need to think of additional ideas if the above doesn't help.  Tim.

Would this affect Sage print preview as well? That's where I'm seeing the slowdown.

That is where I am seeing the slowdown as well. It seems to take a few seconds after I hit the Print Button in a report, then when the little spinner stops after a few seconds, it takes at least 17-20 seconds to render it to Preview. When you actually send it from the preview to the printer it is fast.

That is where I am seeing the slowdown as well. It seems to take a few seconds after I hit the Print Button in a report, then when the little spinner stops after a few seconds, it takes at least 17-20 seconds to render it to Preview. When you actually send it from the preview to the printer it is fast.

Yes, this greatly affects the Print Preview as the Crystal Reporting engine uses the actual print driver to render the Print Preview.  This is why running the same report using different default printers can produce different results such as margin sizes and even slightly different fonts depending on the driver.  Also, you might notice when you render a print preview using a PDF virtual printer it might come out perfect but when using a print driver you see lines slightly out but then when you go ahead and convert it to PDF it turns out fine anyway.  It can be a little frustrating.  I think Crystal does this to ensure WYSIWYG if you actually print to paper.

This reminds me - one thing you can try if not physically printing to paper is to simply install (if not already present) a local Print to PDF driver like Microsoft Print to PDF or CutePDF Writer onto the RDS server and use GP to set it as the default printer for all your users.  The speed difference is usually significant.

Finally, some reports are slow to preview if there is a lot of data and the data isn't well indexed in SQL.  Always ensure you're doing regular SQL index maintenance, I recommend the classic Ola Hallengren maintenance plan you can find here (provides a simple .SQL file).  Also use datapipe reports instead of table reports where possible if you think its a data volume issue.