Skip navigation

APIs can be very useful to automate processes and integrate systems. VMware Workspace ONE Access has a full set of REST APIs that you can leverage.


The steps below will show you the basic steps to connect to a Workspace ONE Access server and send an API request:


1. Login to your Workspace ONE Access environment as admin. On this example I am using Google Chrome, so the following options may vary if you are using a different browser.


Screenshot 2020-01-22 at 13.27.47.png


2. On the "Dashboard" page, press F12 to view the Developer Tools. Alternatively, navigate to Menu (tree dots) > More Tools > Developer Tools.


Screenshot 2020-01-23 at 10.08.35.png



3. Select the Application tab and then expand Cookies.


Screenshot 2020-01-22 at 15.54.09.png


4. Under Cookies, select your IDM URL, highlight the HZN cookie and copy its Value.


Screenshot 2020-01-23 at 10.10.27.png


5. Open your API client tool. On this example I am using Postman (


6. Select your API request method (e.g. GET) and enter the URL for it. Under the Header tab, enter the following:


Key: Authorization

Value: HZN <Cookie value copied on step 4>


Screenshot 2020-01-22 at 14.00.24.png



7. Enter any other required fields (depending on your request) and click Send.



More information, including a list of the API calls that can be used with VMware Workspace ONE Access, can be found at:






The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

Typically, on an highly available Identity Manager deployment, initially the first server is configured and services such as the KDC (used for iOS Mobile SSO) are initialized. After that, this server is cloned and the 3-node cluster is formed.


The KDC service is usually initialized by running the following command:


/etc/init.d/vmware-kdc init --realm YOURKDCREALM.COM --subdomain



There might be a case where you need to change the KDC realm or subdomain after the cluster is already up and running. If you simply run the vmware-kdc init (...) --force command on all servers, they will no longer share the same configuration and you will probably get error messages when configuring iOS Mobile SSO.


A solution for this is to re-configure KDC on the first IDM node, export this configuration and import it on the other nodes.


First IDM node:

In order to re-configure KDC, you can use the following command:

/etc/init.d/vmware-kdc init --realm YOURNEWKDCREALM.COM --subdomain --force


To export the new configuration, use the following command:

/etc/init.d/vmware-kdc dump <filename>


As a <filename> I normally use /tmp/kdc-cfg.tar


Use your preferred tool to copy the configuration file to the other servers.



Second and third nodes:

Change the ownership of the configuration file:

chown horizon <filename>


Re-configure KDC with the new parameters and then import the new configuration file:

/etc/init.d/vmware-kdc init --realm YOURNEWKDCREALM.COM --subdomain --force

/etc/init.d/vmware-kdc load --force <filename>


Restart the server






The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

ralbertodacu Novice
VMware Employees

Running Hyper-V on a VM

Posted by ralbertodacu May 4, 2019

A few days ago I was doing some testing with Hyper-V. As I can easily create a Windows Server using vSphere (6.5 in my case), I decided create my Hyper-V host on a VM.

In order to get this to work I created a VM running Windows Server 2019 and then I needed to do some customization to it.


VM CPU Settings


When creating the VM, change the CPU/MMU Virtualization settings to Hardware CPU and MMU.


Screenshot 2019-05-04 at 13.47.39.png


After the VM is created, make sure it's Powered Off, and navigate to its folder under the Storage menu on vSphere.

Download the <VM Name>.vmx file to your PC and open it with a Text Editor.


In the end of the file, add those lines:


hypervisor.cpuid.v0 = "FALSE"

vhv.enable = "TRUE"


Screenshot 2019-05-04 at 13.57.09.png


Save the VMX file and upload it back to the VMs folder. In my case, instead of overwriting the file in the datastore, I renamed it to <VM Name>.vmx.old.


Screenshot 2019-05-04 at 12.58.33.png



Installing Hyper-V


Power on the VM, install Windows and VMware Tools if you haven't done so, and then go to Server Manager.

Click Add roles and features and follow the wizard to install Hyper-V.


Screenshot 2019-05-04 at 14.22.40.png


Restart the Server as requested, then launch Hyper-V Manager.


Screenshot 2019-05-04 at 14.31.01.png


As a quick test, create a new VM with the default values (click New > Virtual Machine and then follow the wizard). From my testing, you would get an error message when trying to Power On this VM if something is wrong with the Hyper-V VM.





After creating my test VM, I noticed that I could not ping anywhere in the network apart from itself and the Hyper-V Host. I checked the Virtual Switch Manager on Hyper-V and also the Networking settings on the VM, and all seemed to be configured as expected. The way I got it to work was by going to the ESXi Console and enabling Promiscuous mode and Forged transmits in the vSwitch that was connected to the Hyper-V Server VM.


Screenshot 2019-05-04 at 00.40.55.png


Screenshot 2019-05-04 at 00.41.10.png







This configuration was done on my testing environment and I cannot guarantee this is fit for production environments.


The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

When troubleshooting networking issues, tcpdump can be a quite useful to help you understand what is going on.

On the Unified Access Gateway, this tool is not available "out-of-the-box". However, it can be easily installed by running a script that is available on the server (when I tested it, I was running UAG version 3.3).


Run the following commands to install it:


cd /etc/vmware/gss-support/



Screen Shot 2018-07-30 at 10.59.13.png


After the installation is complete, you should be able to run tcpdump commands on the server.




The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

ralbertodacu Novice
VMware Employees

Pull Relay Servers

Posted by ralbertodacu Jun 29, 2018

When utilizing Relay Servers, there are two ways the files can be sent from the Workspace ONE UEM console to the Relay Server: Push and Pull.


On a Push configuration, the files are sent to the Relay Server via an FTP connection (FTPS and SFTP are also supported). That means that SaaS users would need a public DNS to make the Relay Server available, so the Workspace ONE UEM server can open a connection to send over the files.


As an alternative, a Pull Service may be installed on the Relay Server. In this scenario, the Pull Service will regularly check the console server for files to download and, when there’s something available, it would download this content and place it on FTP home directory. Since the Pull Service is the component that opens a connection (HTTPS) to the Workspace ONE UEM console, there’s no need for it to be public.


Note that the Pull Service is only responsible for downloading files from the Workspace ONE UEM environment. The Relay Server still needs an FTP service running, so the devices can reach out to it to download packages.


Below is a diagram of how this communication would look like:


Screen Shot 2018-06-30 at 02.05.08.png



When installing the Pull Service, you will need both the Installer and the Configuration File (PullServiceInstaller.config). The Configuration File looks like the following:


<?xml version="1.0"?>




    <endPointAddress>https://<Console Server URL>/contentpull</endPointAddress>



Make sure you adjust the libraryPath and the endPointAddress accordingly before running the installer.



Outbound Proxy


In some cases, your internal network might need an outbound proxy, so the Relay Server can communicate to the SaaS environment. As the Pull Service installer does not give us an option to configure an outbound proxy, I got around this by doing the following:


1. After installing the Pull Service, the installation folder will have a file called AirWatch.Services.PullService.exe.config. This file will look like this:


<?xml version="1.0"?>









2. Between <configuration> and <appSettings>, add the following:



    <defaultProxy enabled="true" useDefaultCredentials="true">

        <proxy usesystemdefault="true" proxyaddress="http://<proxy_address>:<port>"/>




Note: Adjust the XML values accordingly.



3. Restart the Pull Service.





If you need to troubleshoot the Pull Service, a Log file is created on the folder where the Pull Service is installed. This log will indicate if files are being downloaded, if there’s any connectivity issues, etc.




The links below point to the documentation on how to install the Pull Relay Service:


Configure a Relay Server:


Create a Windows-Based Pull Service Relay Server:


Create a Linux-Based Pull Service Relay Server:




The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.

Even though some of the components of the UAG appliance can be fully configured from its web console interface, you may want to have remote access to the box itself for troubleshooting.

By default, SSH access is disabled on the appliance, but it can be easily activated.


Below I put together some steps to enable SSH on the UAG appliance:


Configure the sshd service:

Open to the UAG server from the vSphere console and login as root.

In order to enable SSH, you will need to modify the sshd_config configuration file, and enable the sshd service on the server.


Edit the sshd_config file. In this example I am using using vi.

On the Linux shell, type vi /etc/ssh/sshd_config and press <Enter>.


Screen Shot 2018-01-09 at 17.20.32.png



Make the following changes to the /etc/ssh/sshd_config file:


  • Change the PermitRootLogin setting from no to yes.
  • Comment the MaxSessions line (add # to the beginning of the line).
  • Comment the AllowGroups line (add # to the beginning of the line).


Screen Shot 2018-01-09 at 17.22.01.png


Screen Shot 2018-01-09 at 17.22.46.png



Save the file: <ESC>, :wq!, <Enter>.



Enable the sshd service:

Use YaST to enable the sshd service.

Type yast <Enter> on the Linux shell to access it.


Screen Shot 2018-01-09 at 17.24.05.png



Navigate to System > Services Manager using the arrow keys and then press <Enter>.


Screen Shot 2018-01-09 at 17.24.28.png



Use the arrow keys to select the sshd service.

Press <Alt>+E to enable the service and <Alt>+S to start it.


Screen Shot 2018-01-09 at 17.26.23.png



To save the configuration, select the OK option by pressing either <Alt>+O or F10.

To exit YaST, select the Quit option by pressing F9.


One way to test it is to connect to itself by typing ssh localhost.


Screen Shot 2018-01-09 at 17.28.43.png






The postings on this site are my own and do not represent VMware’s positions, strategies or opinions.