The print button is the most pressed and most cursed button in every Tally on Cloud office. Here are the five real reasons cloud printing fails - none of them are your printer's fault.
Nothing is more frustrating than accounting software that works perfectly until you press Print. Staff blame the printer, the internet, and Tally in turn - but cloud printing fails for specific, understandable reasons. Once you know which of the five you are facing, the fix stops being guesswork.
Classic Windows printer redirection has one hard rule: the server must render the print job, so the server needs the exact driver for your exact printer model. Your office buys a new printer, connects it to one PC, and it prints beautifully - locally. Inside the cloud session it either does not appear at all or appears with a generic driver that prints garbage.
Multiply this by every user and every printer model in the office and the server collects dozens of third-party drivers. That pile of drivers is the number one cause of print spooler crashes on terminal servers - one bad driver takes printing down for everybody, not just one user.
With standard redirection, Windows creates your printer inside the session with a session number attached, something like HP LaserJet (redirected 7). Tomorrow it may be (redirected 12). Tally remembers a printer by name, so the printer Tally saved yesterday does not exist today. The result is the daily complaint - "Tally forgot my printer again" - and staff re-selecting printers every morning.
Applications print to the default printer of the session, and that default is decided on the server side. This is exactly the pain shown in the video with the TSplus Universal Printer: it prints through one default, so with four printers in the office someone is always opening settings and changing the default before printing an invoice, then changing it back before printing a report. Nothing is technically broken - the workflow itself is broken.
Microsoft's Easy Print was meant to fix the driver problem by rendering through XPS on the client. It helps, honestly, but it has limits: some printers and some advanced features (trays, duplex, special paper sizes used in invoice stationery) do not survive the XPS pipeline correctly. Printouts come out with wrong margins, wrong paper size, or features missing - which is why CA offices with pre-printed stationery often find Easy Print unacceptable.
Without compression, a rendered print job can be many times bigger than the document. Over an office internet line shared by ten Tally users, one big report can take minutes to reach the printer and block the session while it travels. Users describe this as "Tally hangs when I print" - Tally is fine, the job is stuck in transit.
See the complete TSPrint and Tally on Cloud setup live on screen, step by step, in the full video.
Watch Full VideoBecause local printing and session printing are different paths. Locally, your PC uses its own driver directly. In the cloud session, classic redirection needs your printer's driver on the server and creates the printer with a changing session name. If either piece fails, the session cannot print even though the printer is perfectly healthy.
On a shared terminal or cloud server, all users share one print spooler service. Print drivers run inside that shared process, so one faulty driver can crash the spooler and stop printing for every connected user until the service is restarted and the driver removed.
It works on day one and becomes the problem later. Every added driver is another chance for a spooler crash, and drivers must be maintained for every printer model every user owns. Driverless tools like TSPrint exist precisely to avoid building that pile.