Everything in this class of tool exists for one moment: a user clicks an icon and the application opens. This page does that moment slowly — one app, one user, end to end — including the three problems that almost always appear the first time.
Choose the right first app: the one your office cannot work without — in most of Technical Anshu's audience that is the accounting or ERP package. If the hardest app works published, the easy ones will follow without drama. Work through the steps in order, and resist publishing the whole software library until this one app has survived a full day of real use by a real person.
Publishing cannot fix an application that misbehaves with multiple users. Before adding it to the console, sign in to the server as a normal user and run the app. Then, if a colleague is available, have a second user session run it at the same time. Watch for classic multi-user traps: the app storing settings in one shared place, licence prompts meant for a single PC, or the app insisting on administrator rights. Solve those at the app level first — your vendor's own guidance for terminal-server or multi-user installs is the right reference.
In the publishing console, add a new application and point it at the program's executable file on the server. Give it the exact name users already call it — this is not the place for clever labels. Most tools in this class also let you choose whether the app appears in the web portal, as a desktop icon, or inside a full remote desktop. Start with the web portal icon: it is the simplest path and the one the video demonstrates.
Assign the new app to your test user, or better, to a group you created for the pilot. Publishing to 'everyone' on day one is how an unfinished setup becomes office-wide confusion. Group assignment is also your future time-saver: when a new employee joins, you add them to groups instead of re-publishing applications one by one.
On a different computer, open the portal address, sign in as the test user, and click the app. The first launch builds the user's profile on the server, so give it a little longer than later launches. Once open, do three real things: open actual data, save a change, and close cleanly. If the app asks where its data lives, point it at the same database or shared folder the office already uses — a published app working on a test copy of data teaches you nothing.
Almost every first publish hits one of these. The app is invisible: the assignment or the user's group membership is wrong. The app opens then closes: the path points at a launcher or shortcut instead of the real executable, or the app fails its own licence check in a remote session. It opens for the admin but not for users: file or registry permissions on the server assume a single-user PC. Fix each at its own level, then publish your second app — the pattern is now yours.
The full on-screen walkthrough — server setup, app publishing and access from anywhere — is in the video above.
▶️ Watch Full VideoUsually permissions. Many desktop applications are installed and tested only as Administrator, then fail quietly for a standard user because they write settings or temp files somewhere a normal account cannot. Test every published app as a standard user before rollout, and fix the app's folder or data permissions rather than making everyone an administrator.
Yes — tools in this class can deliver a full remote desktop as well as single apps, and some users prefer the familiar desktop. Single published apps are usually the better default: they open faster, look cleaner, and keep users inside the work applications instead of wandering the server's desktop.
Check the application's licence and the vendor's multi-user guidance first. Some software is licensed per device or designed for one user per machine, and a remote session counts differently. The honest routes are the vendor's server, multi-user or cloud edition of that app — publish everything else, and treat that one app as its own small project.