How MSPs Can Manage Client Software Installation Requests

A software installation request is a request to change a managed working environment, not simply an invitation to run an installer. A client employee may have a legitimate need for an application, yet the managed service provider must still determine exactly which edition is required, who can authorise it, what licence permits its use, which information it will handle and how the device will remain supportable afterwards. An approved installation can fail operationally if the employee cannot open the required file, a dependency is missing or the product silently changes an existing application.

For a small MSP, the efficient approach is to separate business approval, technical assessment, controlled delivery and acceptance. These are different decisions and should have different evidence. A product already listed in a managed software catalogue may need a straightforward authorised assignment; an unfamiliar utility requiring elevated drivers and access to client financial data deserves substantially more scrutiny. Neither urgency nor a vendor download link removes the client's approval requirements. The following method assumes the MSP acts only within its actual service contract and that the client's designated owner makes commercial and access decisions.

Establish the requester's authority and the actual business task

Accept the request through the contracted service route and assign a stable ticket reference. Record the client, requesting employee, target device or managed group, intended use and business owner who can authorise the change. A colleague forwarding a download link is not the same as a licence owner approving installation. Ask what job the software must support: preparing a specialist report, opening a supplier file or using a feature not available in the existing application catalogue. This question may reveal an already approved programme that avoids unnecessary purchasing and support overhead.

Distinguish access to an existing licensed product from installation of a new package. Sometimes the actual barrier is a missing account entitlement, wrong file association or a feature disabled under the client's configuration. Installing a second copy will not necessarily help. A good service desk clarifies the requested outcome without asking the user to diagnose the cause. It also checks whether the work belongs to the agreed support contract or needs separately approved procurement and professional services.

Record the client's approval decision and any boundaries: specified users, sites, project duration or data classifications. If a user's job changes, that business authorisation should be revisited. Never treat a request to 'install for everyone' as approval to deploy to an entire client estate without establishing the scope and impact.

Resolve the exact publisher, edition and distribution source

Product names are often ambiguous. A utility advertised under one brand may have free personal and paid commercial editions; a supplier may supply a plug-in alongside its main application; and a similarly named download can be distributed by an unrelated publisher. Confirm the full product name, vendor, version, supported operating systems and the authorised distribution channel. Do not obtain the package from a random mirror merely because the first link in a search result looks convincing.

Assess the source of the installer under the organisation's security policy. Depending on the client, this may involve a trusted application catalogue, publisher signing, malware scanning, software inventory or a vendor-supported enterprise package. These checks reduce ambiguity but do not guarantee that every signed application is suitable or secure. A package may be genuine yet require access the client is unwilling to grant. Capture the version and package identity so another technician can understand what was actually approved when an update or incident occurs.

Confirm the licence terms with the authorised commercial owner. A successful installation and a publicly accessible download do not establish commercial entitlement. Clarify whether the agreement is per user, per device, subscription or another defined model; check activation, expiry, transfer and supplier-support conditions. If no entitlement exists, record a pending procurement decision instead of quietly installing an unlicensed evaluation copy for production work.

Assess compatibility, data handling and privileged requirements

Compare the vendor's supported configuration with the target device's managed operating-system version, available storage, architecture, hardware, current applications and security baseline. Identify dependencies such as a runtime, browser extension, database client, service account, driver or access to a supplier endpoint. Do not copy a setup that worked on a different client's machine without checking the actual environment. A programme can start successfully yet cause conflicts with an existing VPN, document handler or line-of-business component after the next reboot.

Examine what information the programme will receive and transmit. Some products request cloud sign-in or upload local files; others install a background service with broad device access. Before moving sensitive client records into a new service, the client's security or information owner must approve the actual data use and terms. Keep vendor credentials, API keys and privileged accounts in approved access systems rather than storing them in tickets or general knowledge articles. An installation request is not authority to weaken antivirus protection or permanently grant local administrator privileges.

For security-sensitive exceptions, document a qualified risk decision and the person who can approve it. If the software conflicts with a non-negotiable security control, do not force installation to satisfy a ticket response target. Describe the incompatible requirement and seek an approved alternative or a supported redesign. Assess whether the application will need patching and who owns that ongoing maintenance, including updates that could change data handling or remove features.

Select a controlled deployment route rather than an ad hoc shortcut

Where the client uses Microsoft Intune, its Win32 app-management documentation describes application packaging, installation commands, detection rules, dependencies and assignments. These are separate configuration elements; an installer uploaded into Intune is not automatically available to every user. Required assignments install automatically for targeted groups, while Available assignments allow eligible users to install from Company Portal. Those behaviours apply to properly configured and supported deployments, not to every executable or client platform. The MSP should verify the actual tenancy, device enrolment and targeting conditions first.

Choose a deployment method proportionate to the request. A single specialist programme for one approved user may not justify an organisation-wide forced installation. A mandatory security or business application may require controlled Required assignment and scheduled communications. Document installer prerequisites, whether a restart is possible, the deployment ring or device group and the intended observation checks. Avoid requiring a user to disable device protections or manually run an administrator installer simply because the package was not prepared correctly.

Microsoft notes that Intune Win32 deployments must use silent installation rather than interactive pop-up prompts. This matters when choosing a vendor package: if a product requires hands-on input, it may need an appropriate supported alternative or a separately approved attended process. Record real limitations rather than claiming the package can be deployed silently without testing it. A detection rule that falsely reports Installed can conceal a failed programme; the user still needs a functional verification.

Prove the application actually works for the requested task

After installation, compare the detected installed version with the approved request and validate the relevant licence and user permission. Open the programme under the correct authorised identity. Test the particular business outcome that motivated the request: perhaps importing a supported file type, connecting to an approved supplier service or producing a report with representative test data. Avoid using another employee's credentials or real customer data merely to make a demonstration succeed.

Check related functions likely to be affected: file associations, launch at sign-in, printing, authentication, extensions, network connectivity and any declared application dependencies. An installation can appear successful at package level while its service fails to start or it cannot see a required licence. Preserve the evidence and the actual error if the user's task remains blocked. Do not close the service request simply because a management console shows a green deployment icon.

Where feasible, confirm an appropriate recovery action for a failed deployment. Uninstalling software may not reverse changes to a local database, saved document format or shared configuration. If the package is going to many devices, test first on a representative supported sample and decide who can pause the wider rollout. Make the receiving support team aware of new symptoms or known limitations and ensure the vendor escalation route is current.

Give the client a clear support and renewal boundary

A specialist application may be installed by the MSP but supported functionally by its publisher. Spell out which party handles setup, patching, licence assignment, data support and vendor cases. The client should not discover during an outage that installation assistance was included but application troubleshooting was excluded. Preserve the approved software version, publisher, package and assigned device or user in the authoritative managed asset or software record.

For temporary tools, identify the authorised end date and what should happen to the licence, local data and package afterwards. Software left on retired devices or granted to users who no longer need it may create both licensing and security gaps. Avoid inventing an automatic removal policy where the client has not approved one; instead record a review owner and the specific decision needed. If a client asks for a commercial licence transfer, check actual vendor rules rather than assuming that uninstalling an application frees every entitlement immediately.

Reconcile the device's current status after significant updates. Some vendor installers replace components used by other programmes or introduce a new service requiring monitoring. The MSP's knowledge base should describe verified application dependencies and the safe first checks for later support, without exposing proprietary activation details or sensitive customer records.

Turn recurring requests into a vetted catalogue without weakening control

Review repeat tickets for products that satisfy a common approved client need. A managed catalogue can make a vetted application easier to find and support, but every new inclusion should have a nominated owner, supported version, licence position, installation configuration and defined update process. The catalogue is not a blanket approval for every user or a substitute for the client's access policy. A software package may be permitted for an engineering group and unsuitable for a general customer-service role.

Analyse failed and delayed requests to identify avoidable gaps: ambiguous product names, unsupported devices, missing licence approval or suppliers offering installers that cannot be deployed through the normal system. Fix the underlying process rather than adding long mandatory forms that do not change the next decision. Verify that completed requests resulted in the intended business task, then track unresolved exceptions separately. A managed software installation succeeds when the client approved it, the device remains supportable and the employee can genuinely use it for the authorised purpose.

Source A: Microsoft Learn, Add and assign Win32 apps to Intune (Windows Intune packaging and Required/Available deployment scope; accessed 30 October 2026). Source B: Microsoft Learn, Manage apps from Company Portal (user self-service and assigned app states across supported platforms; accessed 30 October 2026). Both references describe particular Microsoft products and do not establish this client's entitlement or approval rules.