Remote Desktop Services are established in many Swiss SMEs. Central applications, consistent workspaces and controlled data storage are particularly well suited to organisations with industry-specific Windows software or multiple work locations.
For the IT provider supporting the customer, however, there is a strategic question: should the platform be operated entirely in-house, or does a managed model make more sense? The answer depends less on the ability to install Windows Server and more on the desired business and operating model.
The real RDSH work starts after go-live
A production RDSH environment consists of more than a session host. Depending on size and requirements, it may include additional components:
- Active Directory and Group Policy
- Remote Desktop Gateway and secure access
- User profiles, for example with FSLogix
- File services and application data
- Licensing and certificates
- Backup, monitoring and capacity planning
- Maintenance windows and user communication
Complexity increases further when multiple customer environments are operated. Standardisation, documentation and clean separation then become more important than individual technical tricks.
When running RDSH in-house can make sense
In-house operation is not inherently wrong. It can work well when an IT provider has sufficient recurring volume, clear internal responsibilities and on-call coverage.
Good conditions for in-house operation
- Several team members with strong Windows and virtualisation expertise
- Established monitoring, backup and documentation processes
- Enough customer volume to justify hardware and reserve capacity
- Defined availability for critical incidents
- Regular testing of recovery and failure scenarios
An IT provider that already operates these foundations for other platforms can integrate RDSH efficiently. Without them, a single-person knowledge risk quickly emerges: one person knows the environment, maintenance is postponed and backups exist but have never been tested.
What changes with a managed RDSH platform
In a managed model, the technical foundation is provided by a specialised operator. The IT provider stays close to the customer and focuses on consulting, applications, users and first-level support.
| Topic | In-house | Managed platform |
|---|---|---|
| Investment | Hardware, storage, backup and reserve capacity upfront | Project- or usage-based entry |
| Expertise | Fully required in-house | Shared between partner and operator |
| Updates | Planned and executed in-house | Platform maintenance within the agreed scope |
| Incidents | Your own team carries the full escalation | Second-/third-level support from the platform operator |
| Brand | Entirely your own platform | Your own brand remains visible with a genuine white-label model |
Managed does not mean the IT provider gives up every responsibility. Applications, customer communication and local dependencies still need a competent partner. The strength lies in a clear division of responsibilities.
Comparing costs properly
A simple price comparison per vCPU or gigabyte of RAM is too narrow. In-house operation also needs to account for:
- Reserve hardware and spare parts
- Backup storage at a separate location
- Monitoring and alerting
- Staff time for updates, maintenance and documentation
- On-call coverage and unplanned incident work
- Tied-up capital and excess capacity
A managed platform is not automatically cheaper. It can, however, make costs more predictable and allow specialist expertise to be used efficiently across multiple partners and environments.
Consider availability, backup and recovery separately
RDSH customers feel even minor disruptions immediately. Yet not every environment should automatically be a high-availability cluster. Three concepts need to be evaluated separately:
- Redundancy: Individual components such as disks can be protected against failure.
- Backup: Systems and data can be restored to an earlier state.
- High availability: Additional systems and mechanisms reduce certain types of interruption.
How long can a customer be without their central workspace — and what are they willing to pay for shorter recovery times? This question should be answered before the architecture is chosen.
Migrating an existing RDSH environment in a controlled way
Before migration, applications, profiles and dependencies need to be inventoried. A sensible process typically includes:
- Inventory of servers, users, data and applications
- Review of licences, printers, interfaces and specialised hardware
- Target architecture and test environment
- Pilot with selected users
- Planned cutover window and rollback option
- Post-migration validation of profiles, performance and backup
A migration is also an opportunity to remove legacy baggage. Not every existing Group Policy or profile issue should be carried over without review.
Decision guide for small IT providers
In-house operation fits when RDSH is a strategic core capability of the business and there is enough staff, volume and operational maturity. A managed model fits when the IT provider wants to retain customer and application expertise while sharing the infrastructure foundation with a partner.
The best decision does not come from a generic rule, but from an honest assessment of volume, expertise, on-call requirements, investment and the service promise you want to make.
White-label cloud and managed-service infrastructure for Swiss IT providers. A service of ScIT Informatik GmbH.