Still broken Tunnel-Config-Page with 19.09.0.17 on my own lab.
Have seen this on three customer installations this week updating, one coming all the way from 9.2.3.x directly to 19.09.0.4 (after DB 9.2->9.3->19.09 of course).
What the heck is going on? One says Site URLs, cannot confirm (can one even hit override for sub-global entries?). A specific patch for 19.07 (15), doesn*t help with 1909..in a deeper inspection the one thing that should be altered in the tunnel appsettings.json isn`t even present (' Usage' ) .Certificate thing on DS? hmm, don´t find anything specific here that makes sense.
It is not only that you can`t access the the TunnelConfig-Page in the Console. You cannot deploy tunnel-profiles anymore, after you have removed them once. The UAG does not find the entry anymore an the service does not start. I can`t even edit a single Apps Assignment where the Tunnel is being configured, I cannot remove the App entirely from the console and re-add it without tunnel-config, I cannot add an assignment.
I opened a ticket with one of my customers (OnPrem 19.07.0.19) an we came to a solution and it was nothing that was mentioned in this thread (the patch 19.07.0.15 comes closest or to be precise, what it actually does, but did not work in my case!), so either there are many different reasons for the issue to occur, or some posts are out of context or simply wrong/misunderstandings or there are just many solutions, this one included.
However, starting with 1907 the way the tunnel/Api access is working changed and somehow might be broken afterwards if it was configured in earlier releases. Check the following on all CS/DS/API-Servers:
Open ' filepath.txt' in ' C: or AirWatch or AirWatch 1907 or Supplemental Software or Tools or UpdateSQLServerInfo' (or ' AirWatch %version%' you are running in the custom path you chose) with Notepad++ and search for ' AirWatch.ApiGateway'
If you find that, you can most likely ignore this post. If not, that's most likely one reason for the issue. Next Search for ' AirWatch.DevicesGateway' and below that line, add:
.. or .. or .. or Websites or AirWatch.APIGateway or Web.config
Safe the file filepath.txt. Then start ' UpdateSQLServerInformation.exe' located in the same folder as admin and click ' Update' . This puts the previous change into the associated config files associated with DB-Access.
Now - according to support - a restart of that server/all servers where you did the change) is recommended. If that`s not possible, restarting the following services might do it:
AirWatch API Workflow
AirWatch Tunnel Service
As always: No Backups, little sympathy. Feeling safer Contacting VMware Support or Partner? Of course, do so!
However, if this has helped you (or not), I would love to know including the version you are running. Thank you!
As you are running UAG 3.7, just in case no edge services and HA come alive after a reboot one day, you are facing the follwoing issue:
Ignore this, if you already fixed this. 😉
So do we know what the official reason for this is and the solution? Here's our situation. We have been running on 18.104.22.168 for a while now. Basically the day the .18 patch came out we have been on it whenever that was. VPN has been working fine. Couple days ago we noticed a yellow triangle next to the VPN Profile on one of our test devices but ignored it since it wasn't the reason for our testing and just thought it was because the Tunnel app wasn't also assigned to the device. So we just setup one of our company presidents new phones and boom his per app VPN won't work and he's annoyed. Now none of the devices will install. So this wasn't necessarily part of an upgrade, happened a while later so find this a bit odd. Also I can not access on the OG that is configured, the Tunnel config in All Settings. I've been off for a couple days but don't think my team has figured it out yet.
Thanks, I'll try applying the latest patch Monday and see what happens. Do we have any idea why it would just work and then suddenly stop? Makes no sense. Looked like most people found it when they updated but mine was working for months before it starting having this enrollment problem.
Errrr. Well I hope it works. That said, I'm going to be a conspiracy theorist and say that it's because they are trying to get everyone to move to the cloud version and these kinds of problems are their way of making you do it. Not the first time something popped up and we all had to react to it to get a fast fix.
By the way updating now. Also does this happen with versions of 19.09 as well? Think my dev environment is on 19.09.04 and one of my team said it has the same problem.
EDIT: Updated the database, device server, and console server. We are going to test enrollment but the tunnel page still errors for us. We are on 22.214.171.124.
EDIT EDIT: Thought I posted an update but guess not. The update didn't help. Enrolling a device still won't accept the tunnel profile.
I contacted support about this because all of the sudden my tunnel profile stopped working. What they said was this was related to an API string in the appsetting.json file where the DB password is not getting update by the tunnel service after a 90 day period. This is why they said we didn't see it right away.
They sent me an updated UpdateSQLServerInformation.exe file which had the same hash as my current file. Here were the instructions to fix:
Oddly enough after a screen share session, it just started working again without running UpdateSQLServerInformation.exe.
Hope this helps.