During my last implementation of UEM which was 1907 I encountered multiple error with tunnel , not the servers or configuration , its in console when I try to open the page it shows the error Workspace one “Page not loading , Go back to the previous page or refresh the page to try again ” once I solved this issue I got another call from other colleagues for error “an error has occurred . something unexpected happened, if the issues persists , please contact you IT administrator
The Problem
Going to instigate these issues like any administrator start normally by checking the console logs and then API logs ,technically you will not find much in console weblog but you may find exceptions and error in API logs , after day of investigation we found its happened because of communication issues and definitely it’s a communication issue with API which could happen when Console try to reach the API server and for some reason the traffic is blocked or routed to wrong directions , thinking for this way make me check the below :
- Check if there is a proxy configured in Concore or API servers (in case of API is not installed with console in same servers)
- Check the Browses IE Proxy and remove the proxy if its configured
- Check the windows service proxy : proxy can be configured in windows as services by command line or by group policy or third part tools , from command line use the command :
netsh winhttps show proxy
to remove proxy :
netsh winhttp reset proxy
- Check if windows firewall is configure in servers : sometime windows firewall
blocking the traffic m so what do you need it to disable the firewall totally or add roles to firewall to allow the traffic flow
- If the API server or console
servers are behind load balancer : in this cases you need to verify:
- Is there any security inspection in the route between API-to-console virtual load balanced URL or from console-to-API virtual load balanced URL : in sch cases call network and security team to solve this issue
- How do you deal with certificate traffic flow between servers which normally it would be :
| mode | Description | Traffic flow | Note | |
| 1 | SSL pass through | SSL terminated in the servers and load balancer will deal with it | Traffic will reach and load balancer as 443 (no decryption or encryption will happen) then from load balancer to servers also as 443 with same certificate (server will decrypt the certificate ) | In such case you need to bind certificate with IIS |
| 2 | SSL offloading | SSL terminated in load balancer | Traffic will reach load balancer as 443 , load balancer will check certificate decrypt the traffic , and then by default the traffic will be in port 80 from load balancer to servers | This will be applied once you “API SSL Offloading ” during the application server setup |
| 3 | SSL bridging | SSL terminated in load balancer and servers will have certificate too (self-sign or public or from local CA) | Traffic will reach load balancer as 443 , load balancer will check certificate decrypt the traffic then re-encrypt , and then by default the traffic will be in port 443 from load balancer to servers | In such case you need to bind certificate with IIS |
Understanding the above will help you to know how to trace the traffic flow between servers :
- Within the API server try to reach the API server URL (http(s)://local host/API/help) it should show the API screen (http or https based on the SSL termination mode , mean in SSL off-loading it will be http and with other modes it will be https ), this just to verify API is working fine locally in each server
- try to reach the API server load balanced URL (https://URL/API/help) it should show the API screen , if no, this mean you have an issue with load balancer or firewall (e.g. load balancer IP in vlan and Servers in different vlan )and need network team help to solve it
- in any of the above cases if API page show “No API found” this mean there is application firewall or URL filtering enabled in firewall of load balancer which need to be checked by network team or security team
- IIS not fully installed : I noticed that some of engineers when they install API /Console services they don’t verified the IIS in the application servers. And they depend on the installed to so , as the installer will not install IIS as per the requirements and always there will me missing features that need to be added ; this can be discovered with Workspace one verification tools which is need to be done before the installation
- After all the above , if still not working the suggestion to open call with VMware support to help and advice.
The Solution
you need to solve the above issues and once its settled its work by diagnostic or by working with support