We just upgraded from 9.2.3.28 to 1811 yesterday.
The steps were to disable and stop the www service on the device services servers.
Run the installers on the Console and DS servers.
When prompted with all services being stopped and to upgrade the DB, we verified all AW services were actually stopped.
Then we upgraded the db to 9.3, then ran the upgrade on the DB for 1811.
When that was done we continued the installers on the Console and DS servers.
Once all was done and all AW services were up, we set the www back to what it was and started it.
Then we went through the verification steps to validate the upgrade and once done with that we upgraded the ENSv1 to get sound back on our Boxer alerts.
So far, so good. Monitoring certificates today because I've read in other threads where that got broken for some after the upgrade.
If no problems pop up we will upgrade the Tunnel, SEG and ACC in a day or so.
Our SEG and Tunnel continued to function without interruption during the Console and DS upgrade.
The upgrade plan says that Tunnel will stop but ours did not.
We started the upgrade at 7:30am and was finished by lunch. Around noonish.
The Windows-Aux-Services will most likely be behind, so an upgrade in a second step should be considered. Depending if each is ' installed separately by the book' they are not affected by an 1811-Upgrade. Upgrading them will cause downtime for the end-users (Emails/Content/Tunnel). If an SEG Classic is put on a DS-Server, it will go down during 1811-update, as the IIS is being stopped.
SEG Classic is version 9.5.0.1 now, Tunnel 9.7.0.0, Content is stuck on 9.2.3.0. ACC and ENS1/2 might be considered as well.
As SEG Classic, Windows and Linux-Content are announced eol by autumn this year, plan migration to UAG (which replaces Content and Tunnel with Per-App-VPN) in a third step. If SEG is not moved to UAG as well by then, consider an Upgrade on SEGv2. With another external Host-Entry and Port, it can coexist with Classic on the same machine. However, if I see 2008R2 still around these days, a new VM with an up-to-date OS is a good idea.
But that's just thinking ahead of the current update you plan.
A few fundamentels should be checked in your Pre-Update-Checklist:
- Check if everything is green: AD Connect, ACC-Connect, CA-Connect, SMTP, SEG, Tunnel, Content, Reports are working, Certificates (APNs, SAN/Wildcards you are using)
- Make a DB-Backup before each DB-Upgrade-Step
- Ensure that you have an BASIC-Console-Administrator working before you do anything. Might be annoying, if AD-Connect is broken in the process and you can't login to console
- As usual: Have a Backup of your machines, Do Snapshots before you start, so you can recover from every situation together with the DB-Backup you made initially
- Disable local Virus-Scanners during the process, Keep track if no ' Monitoring' is starting your AirWatch-Services again automatically during the process
So far we've had nothing like what you've experienced. One thing I do though is once the installers on the Console and Device Services servers reach the point where they display the message to upgrade the database is to wait a few minutes to make sure none of the services try to start back up. I had this happen to us when we did the upgrade to 9.2 and we had to role back and start over. I waited a few minutes the next go round and wound up having to disable a few of the services because they kept trying to restart. It was strange because the error action for them was not set to try restarting if they were stopped. We didn't experience that with this upgrade.