All fixed.

For anyone experiencing the same I suggest you check the following: -

* Your DMA (Device Management Address) FQDN is set to use the correct FQDN your devices will use for connecting to MC within the MCAdmin utility on the server.  If your device connection FQDN is different to that set in the MC config (i.e you have different FQDN's for internal and external access as we do) it wont work.

* Port 443 is allowed inbound to the MC server from devices (the device agent) as well as 5494

* If your DMA FQDN needs to be changed, once done ensure you generate a new "Deployment Server Extensions & Web Console" certificate within the MCAdmin utility on the server and apply it, otherwise you will experience a certificate warning on the devices when the Device Agent tries to connect to the server (as the FQDN it is connecting on will not match that published on the server).  That said if your FQDN is the same for internal and external connectivity you wont have to worry (in my case they are different).

* To ensure no outbound connectivity issues, unless your security policy dictates otherwise suggest you allow the MC server itself unfettered outbound access to the internet.  Its more simple than locking it down then having to punch the relevant holes.

Our problems were three fold: -

* Our firewall was not allowing 443 connectivity from the device agent to the MC server.  Even when we put the correct rule in, it did not work but we found that another 443 blocking rule we had added for another purpose was being matched.  Moving the new allow 443 rule above this matching block rule fixed that issue.

* Our DMA address had to be changed.  It was set to the internal FQDN of the MC server, our devices use a different (external DNS) FQDN to connnect to MC.  Changing this to the correct external FQDN fixed the issue.

* Upon changing the DMA address, we had to generate the new DSE & Web Extensions certificate as mentioned above.

As soon as the above steps were completed almost immediately I was able to see profile information in the device agent, application catalogue functionality started working properly and the Google account configured on the device.

Hope this ends up helping someone.

Cheers

Paul

I'm fairly certain you need 443 as well. 

Thanks Matt, I'll take a look at the firewalling and make sure its allowing 443 inbound from the internet to the server also

Hi Matt,

So Outbound the server is able to access anything on the internet on any port.

Inbound the firewall allows 5494 and 5495 from the internet to the server for device connectivity.

I'm certain some required connectivity is being blocked somewhere but unsure where exactly.  Finding this all a bit of a puzzle and the SOTI network port listings in the help file do not really provide any answers.

Appreciate your help.

Paul

Hello Paul, 

Thank you for requesting a response from SOTI Support Staff. 

Here is a link to a list of all the required ports when configuring MC especially the later versions.  Please note that Google play does use 443 to communicate to the DS. 

https://www.soti.net/mc/help/v14.0/en/setup/installing/network_ports.html

Hope this helps, 

Thanks for this.  So do I take it that I need to allow Google inbound access on 443 to the MobiControl server.

The devices themselves are just internet connected (not Private APN) so they have free and unfettered access to Google services.

Paul

Hi Paul, 

Yes this would be required so that the DS/MS can communicate with Google for configuration details. 

Hope this helps,

Is there any formal SOTI documentation on what access you need between the devices, the MobiControl server, and the Play Store for an Android Enterprise deployment?

Hi Matt,

I have to say I think the port requirement instructions could be clearer.  The port list I think should really advise for each port between which components and whether the requirement is inbound/outbound etc.  Would make life easier.

Paul

Have a possible resolution to this, still to be proven however.

I found having thumbed through the documentation some more that my DMA (Device Management Address) was set to the servers internal FQDN and this should be set to the external (or whatever the FQDN the devices are typically using for management purposes).  I have now changed this to the external FQDN. I now just need to allow port 443 from the internet to the server and hoping everything should then work as expected.

The DMA tends to default to the servers base FQDN (normally internal)......I guess if you were using a DNS alias that was both internally and externally addressable it would never be an issue.

I am a remote worker so having to use the internet for my testing, suspect had I had a device connected to my corporate WiFi (and as such the DMA FQDN would have been valid, and 443 likely accessible from the local LAN) all this likely would have worked.

Once the firewall changes have been made, I will test and report back.