Wait a Minute, Omnissa Workspace One also Supports Servers?

Introduction

Unified Endpoint Management sounds amazing because it's "unified" and promised a single platform nirvana for managing all your devices and operating systems. However, that was never really the reality because unified endpoint management always had an important boundary: it generally stopped at server operating systems. 

Companies could use modern, cloud-based platforms to manage Windows desktops, laptops, mobile devices, Macs, Linux endpoints and rugged devices. Windows Server, however, usually remained dependent on Microsoft Configuration Manager, commonly called SCCM, Group Policy, Windows Server Update Services, PowerShell and other server-specific management tools.

Omnissa Workspace ONE Server Management changes that model.

With Workspace ONE UEM 2604, Omnissa has introduced support for managing Windows Server 2016 and later, including both Desktop Experience and Server Core installations. Instead of introducing a separate server-management product, Omnissa extended the same Intelligent Hub-based architecture already used to manage other Windows endpoints.

The result is an important expansion of what modern endpoint management can include.

Why Windows Server was traditionally excluded from MDM

Most modern Windows MDM solutions rely heavily on the management framework built into Windows client operating systems.

That framework uses Microsoft Configuration Service Providers, or CSPs, to configure the operating system. OMA-DM provides the communication channel through which an MDM platform delivers those configurations.

Windows 10 and Windows 11 include the required native management components. Windows Server does not include the same native OMA-DM functionality. This is one reason Microsoft Intune supports Windows client editions but does not list Windows Server among its supported managed operating systems.

Historically, that created a clear division:

• MDM and UEM platforms managed desktops and laptops.
• Traditional systems-management platforms manage Windows Server.

Omnissa said the heck with that and decided to approach the problem differently.

Omnissa rethought where Windows management happens

Rather than treating Microsoft's native MDM framework as the only way to manage Windows, Omnissa progressively moved more management functionality into Workspace ONE Intelligent Hub.

Intelligent Hub has evolved from a supplemental endpoint agent into a management engine capable of:

• Installing and removing applications
• Applying configurations
• Running PowerShell scripts
• Collecting custom information
• Evaluating device state
• Enforcing security baselines
• Orchestrating multistep workflows
• Initiating remediation
• Managing Windows updates
• Supporting remote administration

This created a Windows management model that does not depend entirely on Microsoft's native MDM stack.

Workspace ONE now supports three general Windows management modes:

• UEM Managed: OMA-DM and Intelligent Hub are both used.
• Intelligent Hub Managed: Management is delivered through Intelligent Hub without OMA-DM enrollment.
• Hub Registered: The device is registered for visibility and selected services but is not fully managed.

Windows Server needs to utilize the Intelligent Hub Managed Mode for windows server operating systems because those operating systems do not provide native OMA-DM functionality. This Intelligent Hub Managed Mode allowed Omnissa to move Windows management intelligence into its own client and make the native MDM channel optional for many important management tasks.

That is what makes Windows Server support possible.

Workspace ONE server management requirements

Omnissa identifies three primary requirements for adding Windows Servers to Workspace ONE:

• Workspace ONE UEM SaaS 2604 or later
• The applicable Server Essentials licensing
• Windows Server 2016 or later

Both Desktop Experience and Server Core installations are supported. Of note and I think it's an important one is that the Server Essentials licensing includes Workspace ONE Assist for remote administration and proxy connectivity so that admins can support server environments remotely and where direct internet access is restricted. This allows for remote access and support of server operating systems without having to purchase a separate tool.

Once the Workspace ONE environment is prepared, enrolling a server is remarkably straightforward.

Enrollment is simple

Provided that Workspace ONE UEM is already configured and ready for server management, enrolling an existing server primarily consists of downloading Intelligent Hub, installing it and supplying the appropriate enrollment parameters.

The current Windows Intelligent Hub installer can be downloaded from getwsone.com. The package is named AirWatchAgent.msi, reflecting Workspace ONE's original AirWatch product history.

Prepare the Workspace ONE environment

Before enrolling the first production server, several settings should be reviewed.

I'd recommend:

• Creating one or more dedicated Organization Group(s) for Windows Servers. Similar to how you've probably already built out your organizational units in Active Directory
• Creating a unique account for server enrollment. Basically a service account
• Enabling Intelligent Hub Managed Mode
• Selecting No OMA-DM Management
• Configuring Single User Mode
• Using a fixed Organization Group assignment
• Reviewing the default action applied to inactive users and devices

These settings help keep servers separated from desktop-management configurations and prevent them from being inadvertently reassigned or wiped because of inappropriate user or inactivity settings.

Create a dedicated server Organization Group

I recommend creating an Organization Group specifically for Windows Server operating systems rather than placing servers into an existing Windows desktop Organization Group.

A dedicated server OG makes it easier to:

• Apply server-specific management settings
• Separate server and desktop policies
• Delegate access to server administrators
• Target applications, baselines, scripts, and patches
• Prevent desktop resources from being assigned to servers
• Report on the server estate independently

Even in a relatively small environment, this separation makes ongoing administration significantly easier.

Use a dedicated enrollment account

Creating a unique, directory-based service account for Windows Server enrollment.

Unlike a desktop, a server should not normally be associated with whichever administrator happens to be logged on when enrollment occurs. A persistent service account provides a consistent identity across the server estate and avoids tying server ownership to an individual employee.

Workspace ONE should be configured for Single User Mode so that enrollment remains aligned with the designated service account rather than transferring whenever another administrator accesses the server.

Although a dedicated service account is not technically required, I strongly recommend using one.

The account should be:

• Restricted to the server Organization Group
• Used only for server enrollment
• Managed according to the organization's service-account standards
• Protected through appropriate credential rotation
• Accessible only to authorized administrators and automation systems

This is especially valuable when enrollment is incorporated into a server-build script, software-distribution platform, or infrastructure automation process.

Command-line or graphical enrollment?

Omnissa supports two Windows Server enrollment methods:

1. Command-line or scripted enrollment
2. Manual enrollment through the Intelligent Hub interface

Manual enrollment is available on Windows Server installations with Desktop Experience. An administrator with sufficient rights can install Intelligent Hub, open the interface, and respond to the enrollment prompts.

Command-line enrollment works with both Desktop Experience and Server Core. It is the practical requirement for Server Core because Server Core does not provide the complete graphical shell needed for interactive Hub enrollment.

I'd recommend the command-line approach personally. Because server deployments are normally automated, the command line approach can run under the SYSTEM account, does not require an interactive enrollment session, and produces a repeatable process that can be integrated into an existing server-build workflow. Also, I've run into issues using the manual Gui install due to windows security policies but I haven't yet using the command line.

Windows Server security does not universally prohibit graphical enrollment. Command-line enrollment is recommended because it is more consistent, scalable, and compatible with Server Core.

Command-line enrollment syntax

Open an elevated Command Prompt or PowerShell session and run the Intelligent Hub installer with the required enrollment parameters.

A basic command is:

msiexec.exe /i "C:\Install\AirWatchAgent.msi" /quiet ENROLL=Y SERVER=<DeviceServicesFQDN> LGName=<GroupID> USERNAME=<EnrollmentAccount> PASSWORD="<EnrollmentPassword>" ASSIGNTOLOGGEDINUSER=N

For example:

msiexec.exe /i "C:\Install\AirWatchAgent.msi" /quiet ENROLL=Y SERVER=ds1234.awmdm.com LGName=WindowsServers USERNAME=svc-ws1-server-enrollment PASSWORD="<password>" ASSIGNTOLOGGEDINUSER=N

The principal parameters are:

Omnissa identifies ENROLL, SERVER, LGName, USERNAME, PASSWORD, and ASSIGNTOLOGGEDINUSER as required parameters for basic silent enrollment. The ASSIGNTOLOGGEDINUSER value must be the final Workspace ONE enrollment parameter in the command.

The exact assignment behavior should be tested with the Organization Group's Single User and enrollment-account configuration.

Add logging and prevent restarts

For production use, I recommend adding verbose installation logging and explicitly preventing Windows Installer from restarting the server:

msiexec.exe /i "C:\Install\AirWatchAgent.msi" /quiet /norestart /L*v "C:\Install\WorkspaceONEHubInstall.log" ENROLL=Y SERVER=<DeviceServicesFQDN> LGName=<GroupID> USERNAME=<EnrollmentAccount> PASSWORD="<EnrollmentPassword>" ASSIGNTOLOGGEDINUSER=N

This provides a local installation log that can be used for troubleshooting or attached to a change-management record.

Protect the enrollment credentials

The example command demonstrates the simplicity of enrollment, but exposing a service-account password directly in a reusable command creates security concerns.

Credentials could appear in:

• Command history
• Script files
• Deployment logs
• Process-monitoring tools
• Screen captures
• Change-management records

A good rule of thumb would be wrapping the command in PowerShell or another secured deployment mechanism rather than unnecessarily exposing the password. Installation under the SYSTEM context is supported.

For a production implementation, consider using:

• A secured PowerShell deployment
• An existing software-distribution platform
• A secrets-management product
• A server-build pipeline
• Infrastructure-as-code automation
• A privileged automation account

Confirm enrollment in the UEM console

After Intelligent Hub installs and enrollment completes, the server appears in:

Devices > List View

The device record can expose information such as:

• Server name
• Windows Server version
• Enrollment status
• Last check-in
• Enrollment account
• Intelligent Hub status
• Installed applications
• Assigned configurations
• Script and sensor results
• Installed Windows roles and features

Workspace ONE provides read-only sampling of installed server roles and features, helping administrators understand which workloads are installed across the server estate.

Give each server a recognizable UEM display name

In my experience, the initial server name presented in the UEM console was generic enough that it became difficult to distinguish one server from another.

I recommend editing the UEM display name immediately after enrollment and applying a consistent naming convention.

Examples include:

• PROD-WEB-01
• DEV-SQL-02
• NYC-RDS-03
• AWS-APP-PROD-01

A useful display name could identify the environment, workload, role, location, cloud provider or sequence number.

Changing the UEM display name does not require changing the Windows computer name. The objective is simply to make the device easy to recognize inside the Workspace ONE console.

This feels like a minor task when enrolling the first server, but it becomes increasingly important as the server population grows.

What can Workspace ONE manage?

So, cool you say but what does this do for me. I agree, enrollment is only useful if the platform can perform the day-to-day tasks required by server administrators.

Workspace ONE Server Management provides a broad set of capabilities through Intelligent Hub.

Security baselines

Workspace ONE supports Windows Security Baseline templates for Windows Server 2016, 2019, 2022, and 2025, including member-server and domain-controller configurations.

Baselines apply during device startup and do not require an interactive user login. By default, they are reapplied hourly, providing ongoing compliance evaluation and configuration-drift correction.

Potential baseline controls include:

• Authentication policies
• Audit configuration
• Windows security options
• Account security
• Firewall settings
• Remote-access restrictions
• Member-server hardening
• Domain-controller hardening

ADMX-based configuration

Windows ADMX Profiles provide more than 350 configuration payloads and resemble the settings administrators traditionally configure through Group Policy.

ADMX profiles can be used for operating-system settings, Windows Update configuration, Remote Desktop Services, and selected applications.

Workspace ONE can coexist with Group Policy, but duplicate settings should be avoided. Two management systems attempting to configure the same setting can create inconsistent behavior and difficult troubleshooting.

Applications and phased deployment

Windows Server applications can be packaged and deployed through many of the same mechanisms used for Windows desktops.

Administrators can:

• Upload internal applications
• Define installation and uninstall commands
• Configure detection criteria
• Target Smart Groups
• Monitor installation status
• Use the Enterprise App Repository
• Deploy applications through Freestyle Orchestrator

Phased Deployment allows applications to progress through sequential Smart Groups. A deployment could begin with development servers, move to test systems, continue to a production pilot, and then reach the remaining production environment.

Omnissa recommends manual progression for servers so each phase can remain aligned with approved maintenance windows.

Scripts and sensors

PowerShell scripts can perform server-specific actions such as:

• Starting or stopping services
• Modifying registry values
• Installing roles and features
• Correcting permissions
• Collecting diagnostics
• Updating configuration files
• Performing pre-patch validation
• Verifying application health

Sensors collect custom information, including:

• Disk-space utilization
• Certificate-expiration dates
• Service status
• Application versions
• Registry values
• Pending-restart status
• Application-health indicators

Scripts provide the action. Sensors provide the evidence.

Together, they give Workspace ONE a flexible mechanism for identifying server state and correcting problems.

Windows Update management

Windows Update behavior is configured through Windows ADMX Profiles.

Granular Patch Management provides more precise control when a specific update must be deployed outside the normal maintenance cycle. Administrators can search for updates, select individual patches and target Organization Groups, device groups or individual servers.

This is particularly valuable for:

• Zero-day vulnerabilities
• Emergency security updates
• Pilot deployments
• Production and nonproduction separation
• Updates that cannot wait for the next routine cycle

Freestyle Orchestrator

Freestyle Orchestrator allows administrators to build conditional, multistep workflows combining:

• Applications
• Profiles
• Baselines
• Scripts
• Sensors
• Conditions
• Validation checks
• Remediation actions

A maintenance workflow might:

1. Check available disk space.
2. Verify that a restart is not pending.
3. Stop an application service.
4. Confirm that a backup completed.
5. Install an update.
6. Restart the server.
7. Confirm that required services returned.
8. Run an application-health check.
9. Escalate the result if validation fails.

This provides a more complete operational process than simply sending a patch or script to a device.

Inventory, intelligence and remote administration

Workspace ONE Intelligence can use server data to create dashboards, reports and cloud-side automation workflows.

Intelligent Hub also supports scripts, sensors, application inventory, update information, and sampling of installed server roles and features.

Workspace ONE Assist

Workspace ONE Assist is included with the server licensing and provides a managed remote-access channel. Omnissa positions Assist as an alternative to routine RDP access where appropriate, communicating over TCP 443 rather than relying on externally accessible RDP services.

Where Workspace ONE server management fits

After all this you might ask, is this the right solution for my company? Workspace ONE Server Management is particularly relevant for:

• Existing Workspace ONE customers
• Cloud-hosted Windows Servers
• Geographically distributed server estates
• Servers outside the traditional corporate LAN
• Horizon and Remote Desktop Session Host infrastructure
• Web and application servers
• Standardized server workloads
• Organizations seeking unified endpoint and server reporting
• Environments that want to reduce traditional management infrastructure

The strongest use case is day-two management: configuring, patching, securing, automating, supporting and monitoring servers that have already been provisioned.

Workspace ONE is not being positioned as a PXE or bare-metal server-deployment product. Its value begins after the operating system exists and Intelligent Hub is installed.

Final takeaway

Workspace ONE Server Management is significant because Omnissa did not wait for Microsoft to bring conventional desktop MDM functionality to Windows Server.

Instead, Omnissa reconsidered where Windows management should occur.

By placing more configuration, software delivery, automation, telemetry, remediation and support functionality inside Intelligent Hub, Omnissa created a management model that can extend beyond devices containing Microsoft's native MDM client.

For organizations already using Workspace ONE, the enrollment experience illustrates the simplicity of that architecture. Download one MSI, run one command, assign a recognizable console name and begin managing the server through the same UEM platform used for the rest of the endpoint estate.

The question is not whether Workspace ONE can manage Windows Server. 

It can.

The more strategic question is whether it can replace Microsoft Configuration Manager for the server-management functions an organization actually needs and uses.

That comparison is the focus of the next article.