Software requests are one of the most common things a service desk actually handles, and SysDesks models them from both ends: the self service portal the user has on their own desktop, and the deployment tooling you use on their behalf. Which one applies depends on why the user cannot install the thing themselves, and that is usually the real question behind the ticket.
The Company Software Portal is an application on the simulated Windows desktop, reachable inside a remote session like any other. It presents the approved application catalogue with a search box, and each entry carries the metadata a real portal shows: the application name and its publisher. The catalogue includes ordinary corporate software such as a document reader, a terminal client, and internally published tools from Northline IT itself.
What the portal does
- Search the catalogue by application name.
- See each application's publisher, so an internally published tool is distinguishable from third party software.
- Install an application that is available to that user on that machine.
- See which applications are already installed rather than guessing from the desktop.
The portal is deliberately the first thing to check. A large share of software tickets are not really software tickets: the application is already in the catalogue, the user simply did not know the portal existed or could not find the entry. Confirming that before doing anything else is faster than any deployment, and it is the answer that leaves the user able to help themselves next time.
When the portal is not the answer, deployment is. The software console lets you push an application to a named workstation, which is the path for machines being prepared for someone, for software a user cannot install under their own rights, and for anything that has to be present before the person sits down at the device.
Deployments can fail, and this is intentional. A deployment that cannot complete reports that it failed rather than silently succeeding, and a failure is information about the target rather than about the button you pressed. A machine that is not reachable, or not in a state where an install can complete, will not accept a deployment simply because the request was well formed. Treating a failed deployment as the start of a diagnosis rather than as an error message to retry is the behaviour the console is built to encourage.
Installation state is shared with the rest of the simulation, which is what makes this worth doing properly. Once an application is genuinely installed on a machine it is installed everywhere that machine is examined: it appears in the portal as installed, it is present in Programs and Features inside the remote session, and it is visible to the resolution conditions on the ticket that asked for it. A ticket that required software to be present will not resolve because you told the user it was done, and it will resolve when the application is actually there.
That connection also runs the other way. Removing or breaking an application changes what the user experiences, which is why software problems in SysDesks are not limited to requests for new tools. A reported fault in an application the user already has is worked in the same consoles, starting from what the machine says is installed rather than from what the ticket assumes.
Rights are the other reason an install fails, and SysDesks models the distinction directly. A standard user who cannot install an approved application has a permissions problem, not a catalogue problem, and the intended resolution is to deploy it for them through the proper channel. Handing the user local administrator rights, or signing in with a privileged account so the installer will run, resolves the symptom while creating a worse problem, and the simulator scores it accordingly.
Installed software is also an asset question. What is on a machine is part of that machine's record, so a deployment you complete is visible from the asset side as well as from the desktop, and a ticket that asked for software leaves behind evidence of what was installed and where. Documenting the install is part of closing the ticket properly rather than an optional extra, which is why the resolution note matters here as much as the deployment itself.