Upgrading to 1811

[AVERYMEADOWS]

Hi everyone,
We're planning an upgrade of our on-prem AW environment to 1811. We're several versions behind, currently on 9.2.3.29. AW support advised us to upgrade to 9.3, then again to 1811. The primary servers to upgrade are the DB, DS, and Console server.
Has anyone upgraded to 1811 using this upgrade path? Are there any pitfalls or 'gotchas' we should look out for? Also, do we need to redeploy any of the appliances or secondary servers following the upgrade (i.e. SEG, Tunnel, CGE, etc)? Many thanks in advance for any information! - Avery

[Stambo]

Hey,
i upgraded some weeks ago from 9.1.3.8 to 1811.
Steps were:
- Database to 9.2 (https://resources.workspaceone.com/view/ywxqvcr4fzp4ccdt7b9l/en)
- Database to 9.3 (https://resources.workspaceone.com/view/5zvdd9ldn7mlzd3723f6/en)
- Full Installer 1811 (https://resources.workspaceone.com/save/9dxrr35zyr28t4yvsndr/en)

upgrade ran smooth without any problems and errors



afterwards i upgraded VMware Tunnel Proxy/Endpoint and Content Gateway
(there was some tricky errors, but with manual removing jre* packages everything works good.)

[sflanagan]

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.

[AVERYMEADOWS]

Okay great! Thank you for your quick and helpful responses Matthias and Steven!
I was browsing other threads this morning as well and wasn't sure how I felt about proceeding. Did you find that the tunnel or email flow through the SEG stopped working following the upgrade? I'm also trying to determine a time frame for how long AW will be unavailable while the upgrade takes place.
Thanks again!

[sflanagan]

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.

[Stambo]

I can't say for sure about the tunnel.
SEG continued without any problems

[LukeDC]

They would advise to go from 9.2 to 9.3 because of the dB. The dB gets an upgrade from 9.2 -> 9.3 after that its the same database right now. The installation after that only updates and changes the dB a bit, not a complete upgrade.

[anonymousmigrat]

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

[AVERYMEADOWS]

Steven and Matthias - Thank you for the information and time frame! That will help us with our planned outage as part of the upgrade process.
Luke - Thank you, that's good to know! I figured there must not have been significant changes if they didn't recommend the usual incremental DB upgrade between AW versions, but I wanted to double-check to make sure I didn't misinterpret anything.
Christoph - Thank you for this information and the additional tips! AirWatch/Workspace ONE is quite a departure from the previous MDM infrastructure that we were familiar with for so long. It's almost a full-time job to keep up with all the changes.

Thank you everyone!

[AVERYMEADOWS]

Hi everyone,

Did anyone experience problems with device enrollment or database inconsistencies following your upgrade to 1811?

We did our upgrade to 1811 and everything completed successfully. However, we now cannot enroll either Apple or Android devices. We use Apple DEP and during enrollment from a factory wiped iPhone, we get an invalid 'profile error'. For Android, we get an error reading that enrollment ' Failed to register google account. Please enroll again' .

When I log in (system administrator level access), I have no problem viewing devices or device details. However, when someone with Help Desk level access logs in, they get an error message when accessing device details. The message is generic and simply reads ' An error has occurred, something unexpected happened.'
Also kind of strange, when I log in with system administrator access, I can see ~650 devices but with a Help Desk login, I only see ~500 devices.

I checked permissions and everything looks as it should whereby the Help Desk has the permissions they need to view device details and such. I opened a support ticket with AirWatch Support and they haven't been very helpful, basically stating that our DB is fine and our DS server is the problem. When we tested our DS server via telnet or through web browser, everything indicates that our DS server is working normally and all services are starting successfully.

Just wanted to see if anyone experienced something like this and if you were able to resolve it. Otherwise, we're contemplating rolling back to our previous version of AirWatch...

[sflanagan]

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.

[sflanagan]

Well, I take that back.  This morning we began experiencing issues with new enrollments and certificate renewals.  They're getting a ' Unable to fetch certificates'  error.
I've opened a ticket with Airwatch.

[JoeTingley]

Steven F, were you able to get your issue resolved?

[sflanagan]

Yes.  We found that LDAP calls to Active Directory were not making it to our domain controllers.
We use certificates for authentication so when a cert was up for renewal the authentication call to AD would fail and the certificate would not get renewed.
Airwatch had already revoked the existing certificate by this time so when the user was prompted to enter username and password it would fail.
This would result in un-enrollment after the designated number of attempts.
We were also unable to perform enrollments because the user authentication would fail.
It turned out to be the AWCM service on our number two server decided after a week that it didn't want to function properly any more.
We wound up having to uninstall, then re-install it.
Luckily we only had around 30 users with certs up for renewal during this time.  It could have been much worse.

[akrowczynski]

Hello,
we also performed an update on Prem from 9.3.28 to 18.11.03, everything went fine but the only problem that we have that Content is not working properly.
All tests in console are running fine, but if you open up the content app no repository anf everything is offline very strange.

Did someone else has a similar problem??

Will open a Ticket to ask support here.

Greetings
Arkadiusz

[SebastianRe]

Someone have a fix on the ' Failed to register google account. Please enroll again'  problem?