Upgraded to SEG V2 and lost connectivity between AirWatch and SEG

[btrabue]

I recently upgraded to AirWatch 9.0.3 and at the same time I also upgraded to the latest SEG V2.  After making the configuration changes in the console I downloaded the SEG installer and installed it on the SEG server.  I performed a test connection and it was unsuccessful.  The ' Connectivity between AirWatch & SEG'  was lost.  I tried several things but they were all unsuccessful.  My only other option that I could see was to install the Classic version of the SEG.  After configuring that and installing the classic version on the SEG all email functions were restored.  My understanding is that this was supposed to be an easy migration.  So far, it has been far from easy.  Has this happened to anyone else and if so, can you please let me know what was done to resolve the issue?  Thank you

[LukeDC]

Since V2 relies on REST, make sure that is up to spec. That's where I would start.

[btrabue]

Thanks Luke!  We use the Rest API for other applications so I'm pretty sure that is ok.  I also have noticed that the SEG service continues to stop on the server. 

[daisukeyajima]

Hi I have the same symptom on my SEG V2 Server.
I also could restore my Email functions only by backing to Classic SEG.
Does anyone use SEG V2 ?
Can I have any suggestion ?

[ligang0424]

Hi
I have the same symptom on my SEG V2 Server.
I installed  a new  environment on
Everhting looks like ok
but the  ' Connectivity between AirWatch & SEG'  was unsuccessful
Can I have any suggestion ?
Thanks

[Chris_Noonan]

Installed v2 in our test environment today but now getting ' Connectivity from AirWatch to SEG'  when testing. In talks with Airwatch Engineers now and will post results here.

[GraemeKingston]

This is happening to me too. I will log a support ticket and post any results here.

[GraemeKingston]

Well I logged a ticket. The support engineer said they were willing to help, but that if they couldn't resolve the issue then I'd need to refer to upgrade support. He would have helped check that our configuration met the prerequisites (they do, to the best of my knowledge). We're SaaS so there may be console settings that I as a customer can't change and would need upgrade support's help to change. Since I have 4 other SEGs still running Classic SEG, I didn't want to risk anything that might compromise the other SEGs. Also SEG V2 doesn't yet support certificate based authentication, which we don't currently use, but we may need later.

I am not pursuing V2 for the time being. It's a new product and I don't think it's yet ready for prime time.

[stadlmeierrolan]

Hi Graeme,
thats the same statement as I got by the support before I updated SEG on our test environment.
They offered an installation service, but not for free (EUR 1200,-!!)
So I tried to update by myself. And it ended up in the same result as you got 🙂 Did you solve your issue with help of the AW support? Or did you take advantage of the installation/upgrade service? And if yes: How did they solve this issue?

Thank you.
Roland

[GraemeKingston]

Hi Roland,

I chose not to pursue V2 now for the reasons above, and reverted to Classic. For me there is no pressing need to ' upgrade'  to V2 now, though I expect I will need to in the future at some point.

regards

Graeme

[SvenJansen]

Hi everybody,

didt anyone resolve the issue? I´m getting currently the same problem upgrading to SEGv2

Thanks!

[Ibbers]

I'm encountering the same issue with a V2 upgrade on a Classic SEG in Shared SaaS.

I'm going to roll back for now, and escalate with AirWatch Support for confirmation of the REST API.

Mercifully I'm only doing this on our non-prod DR SEG, so impact is non-existent.

[J4yJ4y]

' Connectivity between AirWatch & SEG'  issue here too, although email and management functionality is working as should.

External settings on email configuration page have not basically changed since SEGv1:
https:// SEG-FQDN /segconsole/management.ashx is continued as it was in SEGv1.

Afaik , this part of the FQDN used to be used in the SEGv1 connection test,
https:// SEG-FQDN/segconsole

it obviously does not work anymore.
Anyone got this fixed?

[CharlesEstacion]

Did anyone get a chance to get this fixed?

[syarbrou]

Johan, if you are still able to use management.ashx then you are where I was.  You are still using Classic.  The way I was instructed to set things up.  Note I wasn't actively using email thru AW yet:

1. Uninstall SEG Classic.
2. Disable IIS Admin
3. Disable WWW publishing service
4. Install new V2 seg

It now runs as a Java app.  ASHX is from the .NET platform and isn't used anymore even though thru the admin console there is still a URL in there pointing to it.  For us we did the above, everything reports back fine on what they call the masked IP page, but our devices get no email.  No errors, but no emails either.

Steve

[syarbrou]

Note even though I did as I list above, I still see references to ashx file which is odd considering this is not a .NET platform anymore so perhaps my AW person was mistaken that we shouldn't see those files anymore?

[JanosMeszaros]

In our case the issue was that the SEGv2 used the Vertx DNS resolver. Before it has worked with IPs (console server, exchange server) but did not with hostnames. After editing the segServiceWrapper.conf file the problem was solved. Add the following property to this config file: ' wrapper.java.additional.27-Dvertx.disableDnsResolver=true'
The Vertx uses netty libaries and that is causing the DNS resolving error. Support is looking into this netty problem.

[btrabue]

We found out that we needed to import the SEG Server SSL Certificate and uninstall the classic SEG installation from the server before it would work.  If we left the classic SEG installed then AW would continue to route traffic through there instead of using V2.

[ThomasCheng]

Thanks Bryan. I fear the same when I upgrade my environment from 9.1.1 to 9.5 and above plus switching over from SEG classic to V2. So sounds like you set up a new server with SEG V2 installed and configured?

[btrabue]

Thomas - No, we actually used the same SEG server.  There was very little downtime and the users were unaffected besides the 10 minutes of downtime that we had.