Managing Multiple Users on a Single Windows Device with VMware Workspace ONE UEM

In today’s blog post, we will discuss how to manage multiple users on a single Windows device using VMware Workspace ONE Unified Endpoint Management (UEM). We will cover how to enable features, register devices, and manage different user accounts on a shared device.

Enable Features and Register Devices

To manage multiple users on a single Windows device with UEM, you need to have the following features enabled in your UEM SaaS tenant:

1. MultiUserPhase1EnrollmentSupportFeatureFlag

2. DeviceStateChannelInterfaceEnabledFeatureFlag

You can enable these features by creating a support ticket with VMware and requesting that they be activated in your UEM SaaS tenant. Once enabled, you must set the “Default Action For Inactive Users” to “Restrict Additional Device Enrollment” in UEM. Additionally, ensure that “Publish Workspace ONE Intelligent Hub” is enabled.

Registering devices as Corporate-Shared is required for managing multiple users on a single device. To register a device, you need the Serial Number of the machine. You can find the Serial Number using the following command in the Command Prompt:

wmic bios get serialnumber

Once you have the Serial Number, log in to the UEM console and go to the “Devices” tab. Click on “Lifecycle” and then select “Enrollment Status.” Click on “ADD – Register Device” and select “Ownership” as Corporate-Shared. Enter the Serial Number, and click on “SAVE.”

Managing Different User Accounts

To manage different user accounts on a shared device, you need to join the device to Azure Active Directory (AAD). You can do this by following these steps:

1. Log in to Windows using a local admin account.

2. Open the Microsoft account window and click on “Join this device to Azure Active Directory.”

3. Type in the first AAD user account and click on “NEXT.”

4. The first account will always get the local admin permission, and all other accounts will get the user account permission.

5. Click on “Join.”

6. Sign out from the windows local admin account and click on “Other user.”

7. Log in with your AAD first user account, and wait until the device is set up.

At this point, you will notice that Workspace ONE Intelligent Hub is installed automatically, which is required to install IH for all users. Never install Intelligent Hub manually for Shared devices.

Start the Hub and log in as the first user. In UEM, check the current user name. Restart the Windows machine and log in with the second AAD account. Start the Intelligent Hub and log in with the second AAD account. Notice the same machine with different user accounts. Also, check the UEM console to see the different user name on the same Windows machine.

Current Limitations of Shared Devices

While managing multiple users on a single Windows device with UEM is possible, there are some current limitations with shared devices. VMware is working to resolve these limitations with upcoming releases. Some of the limitations include:

1. Only Azure AD users can be managed as Corporate-Shared devices.

2. Only one user can use the device at a time. If multiple users try to log in simultaneously, only the first user will be able to access the device.

3. The device will always enroll using the first user’s credentials, even if other users attempt to enroll the device.

4. Users will not be able to use their own credentials to enroll the device.

5. Shared devices do not support Fully OOBE with Windows Autopilot. You must use the Azure AD join method to connect the device to Azure AD.

Conclusion

Managing multiple users on a single Windows device with VMware Workspace ONE UEM is possible by enabling specific features, registering devices as Corporate-Shared, and joining the device to Azure Active Directory. While there are some current limitations with shared devices, VMware is working to resolve these limitations with upcoming releases. With this information, you can effectively manage multiple users on a single Windows device using UEM.

Configuring Horizon Smart Policies with DEM and Horizon Client Properties

In this blog post, we will discuss how to configure Horizon Smart Policies with DEM (Desktop Environment Manager) and Horizon Client Properties to allow endpoints joined to a specific domain to use the clipboard. We will also explore other options available in the Horizon Client Property registry key and show you how to configure them in your environment.

Before we begin, it’s essential to understand that the steps outlined in this blog post are for educational purposes only and should not be attempted on a production environment without proper testing and validation. It’s also important to note that the screenshots and options may vary based on your Horizon version and configuration.

Step 1: Open the Registry on a Virtual Desktop

To configure Horizon Smart Policies with DEM and Horizon Client Properties, we need to open the registry on a virtual desktop. To do this, log in to a virtual desktop through the Horizon Client, and then follow these steps:

1. Press the Windows key + R to open the Run dialog box.

2. Type regedit and press Enter.

3. Navigate to the following registry key: ComputerHKEY_LOCAL_MACHINESOFTWAREVMware, Inc.VMware VDMSessionData1

This registry key contains all the options available for use with Client Property in DEM Conditions. In our case, we will use ViewClient_Machine_Domain.

Step 2: Create a Condition Set in DEM

Open DEM and create a new condition set. In the condition set, select the Property drop-down menu and choose Is equal to. Then type your domain name (Lab.local) in the Value field. This will create a condition set that allows endpoints joined to the Lab.local domain to use the clipboard.

Step 3: Create a Horizon Smart Policy

Next, we need to create a new Horizon Smart Policy and bind the condition set we created to this policy. To do this, follow these steps:

1. Open DEM and go to the Policies tab.

2. Click the Create Policy button and select Horizon Smart Policy from the drop-down menu.

3. Enter a name for your policy (e.g., Allow Clipboard for Lab.local Endpoints) and click Next.

4. Select the condition set we created earlier and click Next again.

5. Enable the Clipboard option, and then click Finish to save your policy.

Now that you have created your Horizon Smart Policy, all endpoints joined to the Lab.local domain will be allowed to use the clipboard when they log in through the Horizon Client.

Other Options Available in the Horizon Client Property Registry Key

The Horizon Client Property registry key (ComputerHKEY_LOCAL_MACHINESOFTWAREVMware, Inc.VMware VDMSessionData1) contains several other options that you can use with Client Property in DEM Conditions. Here are some of the most commonly used options:

1. ViewClient_Machine_OS: This property specifies the operating system of the endpoint device. You can use this property to allow or block specific OS versions from accessing the Horizon environment.

2. ViewClient_Machine_Architecture: This property specifies the architecture of the endpoint device (e.g., x86 or x64). You can use this property to restrict access to specific architectures.

3. ViewClient_Machine_Language: This property specifies the language of the endpoint device. You can use this property to allow or block access based on the user’s language preferences.

4. ViewClient_Machine_UUID: This property specifies the unique identifier of the endpoint device (also known as the universally unique identifier or UUID). You can use this property to identify specific devices and apply policies accordingly.

5. ViewClient_Machine_Manufacturer: This property specifies the manufacturer of the endpoint device. You can use this property to allow or block access based on the user’s device manufacturer.

6. ViewClient_Machine_Model: This property specifies the model of the endpoint device. You can use this property to allow or block access based on the user’s device model.

7. ViewClient_Machine_BIOS: This property specifies the BIOS version of the endpoint device. You can use this property to allow or block access based on the user’s BIOS version.

8. ViewClient_Machine_Firmware: This property specifies the firmware version of the endpoint device. You can use this property to allow or block access based on the user’s firmware version.

9. ViewClient_Machine_Hardware: This property specifies the hardware version of the endpoint device. You can use this property to allow or block access based on the user’s hardware version.

10. ViewClient_Machine_Software: This property specifies the software version of the endpoint device. You can use this property to allow or block access based on the user’s software version.

Conclusion

In this blog post, we have shown you how to configure Horizon Smart Policies with DEM and Horizon Client Properties to allow endpoints joined to a specific domain to use the clipboard. We have also explored other options available in the Horizon Client Property registry key and showed you how to configure them in your environment. Remember to test your policies thoroughly before deploying them to your production environment.

If you found this blog post helpful, please share it with your colleagues and friends who work with Horizon. We value your feedback and would love to hear your comments and suggestions for future blog posts.

Here’s the 500-word blog post based on the information provided:

Port-Based Authentication is a security feature that allows only authorized client devices to access the network. In order to prevent unauthorized devices from gaining access, some organizations use Port-Based Authentication. To enable this feature, the client device must have a certificate. Integrating an internal Certificate Authority with Workspace ONE UEM allows you to provide computer certificates to client devices.

To begin, open the Certification Authority and right-click on Certificate Template. Click on Manage and then right-click on Computer to duplicate the template. On the General tab, change the name of the template to ComputerUEM. On the Subject Name tab, choose the Supply in the request. On the Security tab, add the account that has Enroll permission.

Next, log in to WS1 UEM and go to All Settings. Click on Enterprise Integration and then click on Certificate Authorities. Click Add and type a name for the certificate authority. Choose Microsoft ADCS and enter the CA server name and authority name. Also, enter the service account username and password. Click Test Connection and then save.

After setting up the certificate authority, you can create a request template in WS1 UEM. To do this, click on Request Templates and type the name of the template, issuing template, subject name, and SAN type. Click Save.

Now, when you enroll a Windows device, the device will receive a certificate with the device UDID, which can be used for Port-Based Authentication. To enable this feature on your devices, follow these steps:

1. Create a new profile in WS1 UEM and select Windows as the platform.

2. Select Device Profile and type the name of the profile.

3. Add a smart group that will receive the certificate.

4. Go to Credentials and configure the CA and template.

5. Save and publish the profile.

With these steps, you can ensure that only authorized client devices can access your network using Port-Based Authentication. This feature provides an additional layer of security for your organization’s network and devices.

Sure! Here’s a 500-word blog post based on the information provided:

Integrating Azure AD with On-premises UEM: A Step-by-Step Guide

If you’re trying to integrate your on-premises Unified Endpoint Management (UEM) solution with Azure Active Directory (Azure AD), you may not see the On-premises MDM application on the list. This can be a bit confusing, but don’t worry – we’ve got you covered! In this blog post, we’ll walk you through the steps to create an On-premises MDM application in Azure AD and configure it with your UEM solution.

Step 1: Sign in to Azure Portal

To start, sign in to the Azure portal at . If you don’t have an Azure account, you can create one for free here.

Step 2: Navigate to Azure Active Directory

Once you’re signed in, navigate to the Azure Active Directory page by clicking on the “Azure Active Directory” tab in the left-hand menu.

Step 3: Click on Mobility (MDM and MAM)

In the Azure Active Directory page, click on the “Mobility (MDM and MAM)” tab. As you can see, there is no On-premises MDM application listed here.

Step 4: Create an On-premises MDM Application

To create an On-premises MDM application, click on the “Add application” button. When you do this, you won’t see an On-premises MDM application to select – instead, you’ll need to create your own application.

Step 5: Create Your Own Application

To create your own application, click on the “Create your own application” button. In the “Create application” page, enter the name “On-premises MDM Application” and then click on “Create”. You’ll see a notification that the application has been added successfully.

Step 6: Configure Your On-premises MDM Application

To configure your On-premises MDM application, go back to the “Applications” tab and select “On-premises MDM Application”. In the “Overview” page, you can configure your UEM solution by providing the necessary details.

Step 7: Verify Your On-premises MDM Application

After configuring your On-premises MDM application, go back to the “Mobility (MDM and MAM)” tab and verify that your application is listed here. If you don’t see it, try refreshing the page or checking again later.

That’s it! By following these steps, you can create an On-premises MDM application in Azure AD and integrate it with your UEM solution. Remember to check the “Mobility (MDM and MAM)” tab to verify that your application is listed – if you don’t see it, try refreshing the page or checking again later.

If you have any questions or comments, feel free to leave them below. Don’t forget to sign up for our newsletter to stay up-to-date with the latest Azure and UEM news!

VMware Workspace ONE UEM Tunnel: Troubleshooting DNS Related Issues

As an IT administrator, you may face issues with VMware Workspace ONE UEM Tunnel occasionally. In one such instance, users reported difficulty in connecting to applications through the VMware Tunnel, even though the VMware UAG Tunnel Edge Service showed a green sign indicating it was up and running. To troubleshoot this issue, I delved into the UAG Debug log and found several errors related to DNS. In this blog post, I will discuss the steps I took to resolve the issue and the causes of these DNS-related problems.

Symptoms of the Issue

———————-

The symptoms of the issue were as follows:

* Users were unable to connect to applications through the VMware Tunnel.

* The UAG Tunnel Edge Service showed a green sign, indicating it was up and running.

* The UEM Tunnel Test Connection showed “No information to display” occasionally.

* The UAG Debug log showed errors related to DNS.

Troubleshooting Steps

———————–

To troubleshoot the issue, I followed these steps:

Step 1: Check the UAG Debug Log

I checked the UAG Debug log and found several errors related to DNS. The errors were as follows:

* “DNS resolution failed for .”

* “Failed to resolve hostname .”

* “DNS query timed out for .”

Step 2: Check the Network Settings

I checked the network settings of the host running one of the DNS servers and found that the NIC was faulty. This was causing the DNS resolution to fail.

Step 3: Replace the Faulty NIC

To resolve the issue, I replaced the faulty NIC with a new one. This fixed the problem, and everything worked properly again.

Causes of the Issue

———————-

The cause of the issue was the faulty NIC of the host running one of the DNS servers. The NIC was unable to resolve hostnames correctly, causing the UEM Tunnel to fail.

Conclusion

———-

In conclusion, if you face issues with VMware Workspace ONE UEM Tunnel related to DNS, you should check the network settings and ensure that the hosts running the DNS servers have proper network connectivity. Replacing faulty NICs can help resolve the issue quickly. Additionally, checking the UAG Debug log can provide valuable insights into the problem and help you identify the root cause of the issue.

FAQs

—-

1. Can I use a different DNS server other than the one provided by VMware?

Yes, you can use a different DNS server. However, ensure that the DNS server is properly configured and can resolve hostnames correctly.

2. How do I check the network settings of the hosts running the DNS servers?

You can check the network settings of the hosts running the DNS servers by accessing the network settings in the VMware Workspace ONE console.

3. What are some common errors related to DNS that I might encounter while troubleshooting UEM Tunnel issues?

Some common errors related to DNS that you might encounter while troubleshooting UEM Tunnel issues include “DNS resolution failed,” “Failed to resolve hostname,” and “DNS query timed out.”

Sure! Here is a 500-word blog post based on the information provided:

—

As a VMware WSO user, I recently encountered an issue while trying to connect my WSO Unified Endpoint Management (UEM) to VMware WSO Access. When I tried to save my configuration, I received an error message saying “Save Failed.” In this blog post, I will show you how I solved this problem and was able to successfully connect my WSO UEM to WSO Access.

Before we dive into the solution, let me provide some background information on VMware WSO and its components. VMware WSO is a cloud-based platform that provides unified endpoint management (UEM) for IT teams. It includes features such as device management, application management, and security management. VMware WSO Access, on the other hand, is a component of WSO that provides secure access to enterprise resources.

When I tried to connect my WSO UEM to WSO Access, I received the “Save Failed” error message. After troubleshooting the issue, I discovered that the problem was caused by an incorrect configuration setting. Specifically, the “Use SSL/TLS” option in the WSO Access settings was not enabled.

To resolve the issue, I followed these steps:

1. Log in to your VMware WSO account and navigate to the WSO Access settings.

2. Click on the “Settings” tab and select the “Advanced” option.

3. Scroll down to the “Use SSL/TLS” option and enable it.

4. Save your changes by clicking the “Save” button at the bottom of the page.

After enabling the “Use SSL/TLS” option, I was able to successfully connect my WSO UEM to WSO Access without receiving any error messages. This solution worked for me, and I hope it helps you as well if you are experiencing the same issue.

In summary, the “Save Failed” error message that appears when trying to connect VMware WSO UEM to WSO Access can be resolved by enabling the “Use SSL/TLS” option in the WSO Access settings. This simple step can help you avoid any further issues and ensure a smooth connection between your WSO UEM and WSO Access.

—

I hope this blog post helps you resolve the issue you are experiencing with connecting your VMware WSO UEM to WSO Access. If you have any questions or comments, please feel free to leave them below. I will do my best to respond to them as soon as possible.

Sure, here is a 500-word blog post based on the information provided:

In my previous video, I showed you how to configure AppLocker with WSO UEM. Today, I want to take you through the user experience of using AppLocker with WSO UEM.

First, let me explain what AppLocker is. AppLocker is a feature in Windows that allows you to restrict which applications can run on your device. This helps to prevent malware and other unwanted software from running on your device.

WSO UEM (Unified Endpoint Management) is a solution that allows you to manage all of your endpoints, including laptops, desktops, tablets, and mobile devices, from a single console. WSO UEM provides a range of features, including AppLocker management.

To use AppLocker with WSO UEM, you first need to have a WSO UEM server set up and configured. Once you have the WSO UEM server set up, you can begin configuring AppLocker policies.

Here’s how the user experience works:

1. The user opens the AppLocker portal on their device. This is usually done by clicking on a link or icon on the device’s home screen.

2. The AppLocker portal displays a list of all the applications that are currently running on the device.

3. The user can filter the list of applications by various criteria, such as the publisher of the application, the date it was installed, and so on.

4. The user can also search for specific applications by typing their name or description into a search bar.

5. Once the user has identified the application they want to block or allow, they can take appropriate action. For example, they might click a button to block the application or another button to allow it.

6. If the user is an administrator, they may also have the option to create custom AppLocker policies for their organization. This could involve creating a list of approved applications, blocking certain applications based on specific criteria, and so on.

7. Once the user has configured the AppLocker policy, they can save it and apply it to their device.

8. The next time the user starts their device, the AppLocker policy will be enforced, and any applications that are not allowed by the policy will be blocked from running.

Overall, the user experience of using AppLocker with WSO UEM is straightforward and easy to use. The portal provides a clear and intuitive interface for managing application restrictions, and administrators can easily create and enforce custom policies for their organizations.

Of course, as with any security solution, there are some potential drawbacks to using AppLocker with WSO UEM. For example, some users may find that certain applications they need are blocked by the policy, which could impact their productivity. Additionally, implementing and managing AppLocker policies can require a significant amount of time and resources, especially for larger organizations.

However, overall, using AppLocker with WSO UEM is a powerful way to protect your devices from malware and other unwanted software. By restricting which applications can run on your devices, you can help prevent attacks and maintain a secure computing environment.

Microsoft AppLocker is a powerful feature that allows organizations to control which applications can run on their systems. When used in combination with VMware Workspace ONE UEM, it provides an additional layer of security for none domain join laptops. In this blog post, we will explore how to configure AppLocker to allow users to launch .EXE files only from the Program Files and Windows directory, while administrators are allowed to launch .EXE files in all directories.

Step 1: Create a Rule

To begin, open the AppLocker settings in your VMware Workspace ONE UEM environment. Click on the “Policies” tab and then click on the “Create Policy” button. Give the policy a name that describes its purpose, such as “Allowed EXE Files.”

Step 2: Add Rules

In the “Create Policy” window, scroll down to the “Rules” section and click the “Add Rule” button. In the “Rule Conditions” section, select “File Name” and then enter the following conditions:

* File Name: *.EXE

* File Location: Program Files, Windows

These conditions will allow only .EXE files to be executed, and limit them to the Program Files and Windows directories.

Step 3: Add Exceptions

Next, you need to add some exceptions to the rule. In the “Rule Actions” section, click the “Add Action” button and select “Allow.” Then, enter the following conditions:

* File Name: *.EXE

* File Location: Anywhere

These conditions will allow administrators to launch .EXE files in all directories.

Step 4: Save the Policy

Once you have added all the rules and exceptions, click the “Save” button to save the policy. You can now associate this policy with the appropriate users or groups in your VMware Workspace ONE UEM environment.

Configuring AppLocker in combination with VMware Workspace ONE UEM provides an additional layer of security for none domain join laptops. By allowing only .EXE files to be executed from the Program Files and Windows directories, you can limit the potential damage that can be caused by malicious software. Additionally, by allowing administrators to launch .EXE files in all directories, you ensure that they have the flexibility they need to perform their tasks effectively.

In conclusion, configuring AppLocker in combination with VMware Workspace ONE UEM is a powerful way to control which applications can run on your systems. By following the steps outlined in this blog post, you can create a policy that allows users to launch .EXE files only from the Program Files and Windows directory, while administrators are allowed to launch .EXE files in all directories. This provides an additional layer of security for none domain join laptops, while still allowing administrators the flexibility they need to perform their tasks effectively.

Integrating Horizon Published Apps with Workspace ONE Access

In my previous blogs, I’ve explained how to use the new Published Apps on Demand feature in App Volumes and consume applications through a Horizon RDSH farm or VDI desktop pool using the Horizon Client. In this blog, I’m going a step further and integrating the Horizon Published Apps with my Workspace ONE (Access) environment. This will provide a central location where all devices can connect to consume applications in a modern way.

Reasons for Integration

————————

There are several reasons why I want to integrate the Horizon Published Apps with Workspace ONE Access:

1. **Centralized Management**: With Workspace ONE Access, I can manage all my applications and resources from a single location. This makes it easier to configure and maintain my environment.

2. **Conditional Access**: With Workspace ONE Access, I can configure conditional access for my applications and resources. This ensures that only authorized users can access the applications, which improves security.

3. **Modern Application Delivery**: By integrating the Horizon Published Apps with Workspace ONE Access, I can deliver modern applications on-demand to all my devices. This provides a better user experience and increases productivity.

Integration Process

——————–

To integrate the Horizon Published Apps in Workspace ONE Access, follow these steps:

1. Log into your Workspace ONE Access tenant and open the Workspace ONE Access Console.

2. Navigate to Resources > Virtual App Collections and click New.

3. Select Horizon as the Type and enter a Name for your new virtual app collection.

4. Select your Workspace ONE Connector and click Next.

5. Add your Horizon Connection Server’s FQDN, Username, and Password to configure the connection. You can also select TrueSSO and Sync Local Assignments if desired.

6. If you have multiple pods, repeat the previous steps for each pod. Otherwise, click Next.

7. Choose the Sync Frequency to Manual, Weekly, Daily, or Hourly. I’ve set mine to Hourly.

8. Optionally, select the Default Launch Client. I’ve selected the Horizon Client instead of the Browser.

9. Click Save to save your virtual app collection.

10. Synchronize your virtual applications by clicking the Sync button and selecting Sync without safeguard to ensure the first sync is successful. You can check the status in the Sync Status field.

11. When the synchronization is complete, navigate to the Virtual Apps tab in the Workspace ONE Access console to find all synchronized applications from your Horizon environment.

12. Now it’s time to test if the Published Apps are also launched on-demand from the Intelligent Hub. You can either open the Intelligent Hub application on your device or the browser.

Testing the Integration

————————-

To test the integration, I opened the Intelligent Hub application on my device and refreshed the portal. Sure enough, I saw all the synchronized applications from my Horizon environment, including Notepad++ (vdi). When I opened Notepad++, I saw a small Horizon icon in the bottom right of my screen, indicating that the Horizon Client was used to log in to my VDI desktop. A few seconds later, the App Delivery message appeared on my screen, confirming that the published app was started on-demand from the Intelligent Hub.

Conclusion

———-

Integrating the Horizon Published Apps with Workspace ONE Access provides a central location for all devices to connect and consume applications in a modern way. This integration also enables conditional access, providing an additional layer of security for our applications. With this integration, we can deliver modern applications on-demand to all our devices, improving the user experience and increasing productivity.

Running Published Apps on Demand from a VDI Desktop Pool

In recent times, VMware has introduced the feature of Published Apps on Demand, which can revolutionize your application delivery strategy and take it to the next level. This feature allows users to access applications directly from the App Volumes manager into the Horizon console without requiring an RDSH farm. However, most blog posts and presentations focus on running published apps from an RDSH farm, leaving out the possibility of running them from a VDI desktop pool. In this article, I will explain how to run published apps on demand directly from a VDI desktop pool, and how to build an On-demand package if you don’t have one already.

Requirements:

1. At least one application package in App Volumes with delivery type set to “On-demand”.

2. An Horizon environment with a published VDI desktop & applications pool.

3. The ability to build an On-demand package if you don’t have one already.

Step 1: Creating an On-Demand Package

If you don’t have an On-demand package, you can create one by following these steps:

a. Open the App Volumes manager and select the application you want to create an On-demand package for.

b. Click the “Packages” tab and click “Add Package”.

c. Select “On-Demand” as the delivery type and click “Next”.

d. Follow the wizard to complete the package creation process.

Step 2: Publishing a VDI Desktop Pool

To publish a VDI desktop pool, follow these steps:

a. Open the Horizon management console and select “Desktops & Applications” from the left menu.

b. Click “Publish” and select the VDI desktop pool you want to publish.

c. In the “Session Type” settings, select “Desktop & Applications” or “Applications” depending on your requirements.

Step 3: Adding a Published Application Manually

Once you have published a VDI desktop pool, you can add a published application manually by following these steps:

a. Open the Horizon management console and select “Applications” from the left menu.

b. Click “Add” and select “Add Manually”.

c. Select your VDI pool from the desktop pool radio button.

d. Enter the application ID, display name, and parameters for the application shortcut. The path should be:

e. The parameters will be different for each application, because of its own GUID. But it should look like this:

f. Click “Submit” and confirm with “OK”.

g. Add an entitlement to the published application and click “OK”.

Step 4: Testing Published Apps on Demand

Once you have created an On-demand package, published a VDI desktop pool, and added a published application manually, you can test the Published Apps on Demand feature by doing the following:

a. Login to a desktop with the Horizon Client installed and log in to the Horizon environment.

b. Open the start menu and find the shortcut for the published application.

c. Click the shortcut to open the application, and you should see a message at the bottom right of your screen saying “App delivery in progress”.

d. When the package is mounted to your VDI, the application will be started and streamed to your local desktop as a Published App on Demand!

Conclusion:

Running published apps on demand from a VDI desktop pool can be a game changer for organizations looking to revolutionize their application delivery strategy. With this feature, users can access applications directly from the App Volumes manager into the Horizon console without requiring an RDSH farm. By following the steps outlined in this article, you can start using this feature today and take your application delivery to the next level.