Hi!

We solved this today. We had not created a Managed Google Play account but a GSuite account. Now we have devices up and running. Thou there is a problem with the Application Catalog rule for which we are waiting for a fix.

Have you created your managed Google Play account?  If so, have you logged in that account on Google's portal and configured apps and other options?

Hi

I have the same problem. My problem was that i forgot to set the "Managed Google Play Account" to "Android Enterprises" in the Add Device Rule

We have 3 customers with the problems of Pending Google Accounts. All are on-premise instances. The devices are enrolled and shown in console, but the pending actions notification remains.

We have upgraded Mobicontrol to latest release but no change.

We have enrolled the same devices, with the same wifi connection, to a cloud instance with no problem. The Google account is assigned to devices in a few seconds, so I think it could be some problem of comunication betewen Mobicontrol and Google, but I have not found any reference on the online help or this forum.

I appreciate your kind help about this.

Is there any error message related to "Empty Token" in the Deployment Server or Deployment Server Extension logs?

Hi Raymond,

Sorry to hijack slightly the topic, but speaking of the Empty Token issue, do you know some known causes to investigate ? We have that issue atm with a new customer.

Hi Laurent,

I'm waiting for reply from Soti support team on this.     I suspect this is related to bug(s) in latest v14.2.x server, which includes some new features to handle managed Google Play store.   Some table(s) in the database may have been incorrectly modified by some new codes that implement the new features.

We have exactly this problem with our test On-Prem v14.3 service.  Server enrols to our Managed Google Play account just fine.  When enrolling a device it never completes the "Google account Completing configuration for your work profile" pending action and we just get lots of "EMPTY_TOKEN" related errors in the device log.

Works just fine in the cloud typically.

We have allowed access inbound from the internet to the server on TCP 443 for Google services (for the sake of testing have allowed any inbound host) but it still does not work.

Rather at a loss as to how to solve this now.

Hi Paul,

With reference to your request for me to provide an answer, I have to say first that I am not from Soti and I don't have a solution yet.

Though I'm still waiting for Soti support team to provide me with solution for this "empty token" problem, I am quite sure the problem has nothing to do with any missing exception to Google services in any firewall, but rather related to corrupted table(s) in the databases due to some buggy codes.  Some time in the near future, they have to roll out a server patch or some SQL script to clean up the mess in the database.

If your server has no enrolled android enterprise devices already deployed to end-user, you have the option to try the following to see if the problem is solved on your server:

1. remove all app catalog rule(s) that include app item(s) associated with the empty "Managed Google Play" account created.

2. remove the add-devices rule(s) that use the empty "Managed Google Play" account.

3. remove this "Managed Google Play" account with empty token.

4. create a new "Managed Google Play" account.

5. add the required apps in your MGA account at Google's Managed Google Play store portal

6. create a new add-devices rule using the new "Managed Google Play" account created in (4)

7. create new app catalog rule(s) that include your required app items

8. factory reset your device and try enrolling it to AE device owner mode with the rule created in (6).

As I need to find a way to solve the problem in case  my corporate/governmental customers' servers face the same problem in the near future, I haven't and won't use the above approach so that I have a server instance to test out any proposed solution(s) given by Soti.

FWIW, our customer that had the issue with the Empty Token, has worked it out.

I don't have the details, will try to, but it was firewall related on the server part, but not that obvious, as the needed ports were already open.

I'll update if I get more details.

I got some details.
This is highly dependant on how the network is setup, but this is somewhat what happened.
The customer had to set the external address as primary and the internal address as secondary (on premise server), and then make sure everything is opened as needed for the external address set as primary.
Then it went through.
With the internal address set as primary, impossible to get it to work.
As I said, this is highly dependent on the network itself, and its routing/firewall part.

Thanks for your replies Raymond & Laurent.

Be interesting to see what SOTI support come back with on your side Raymond.

As to the config on my server, My MC services Primary Management Address is set to the internal server name, the Primary Agent Communication address the external server name (NAT'ted Public IP with associated DNS record) and the Secondary Agent Communication address is the internal server name.

Does this sound correct, or should the Primary Management Address of the server be the external DNS name?  If this is changed I assume this will require regeneration of some of the certification on the server?

Thanks for your help chaps appreciated.

Paul

Well everyone think I may have found my issue.

Looks like my DMA address was configured for our servers internal FQDN.....so even with port 443 allowed can only assume devices were trying to communicate with DS using the internal FQDN that it wouldn't of course be able to resolve from the outside world.  I expect if I were sat on our corporate LAN it would have all worked as expected.

I have changed the DMA to the external FQDN, just awaiting a colleague to adjust the firewall accordingly (allow the devices to connect to the server on 443 as well as 5494) and hopefully all will then be well.  Usefully our DNS service operates split-brain DNS so the external FQDN can be resolved to the internal address within the corporate LAN, so the change should not affect LAN based connectivity (i.e WiFi in the office) if we ever wanted to use it.

Will keep you posted.

Paul

Hello Paul, 

Thank you for requesting a response from SOTI Support Staff.

I agree with Laurent, both you and he have hijacked Johan's post. ;)

Nonetheless we are glad that all 3 issues seem to be resolved within the one posting, unfortunately we cannot "solution" the post more than once.

I see that Raymond has a pending case and working with SOTI Technical Support to resolve his circumstances as well.

Your issue and the required resolution make a lot of sense as to why this was occurring, however hard to trouble shoot without a visual or the full configuration details.  Nonetheless, if it is resolved, I will wait for your confirmation that it is resolved before locking the post.

Also here is a link to details on how to configure the Administration Utility, for future inquiries, that may come in handy.

https://www.soti.net/mc/help/v14.0/en/adminutility/reference/dialogs/adminutility/deployment_server.html

Cheers,

Today I upgraded our test server from 14.2.2 to 14.3, and I think I'm on  the same boat as Raymond.

Server is cloud based (not soti though), all needed ports are opened, and confirmed open with telnet, no FQDN name, only a single public IP address everywhere.

Worked perfectly with 14.2, dead in 14.3

I tried my best, so I'm confident the issue is Soti related.

I will follow Raymond's case if he gives updates here ,at the same time I opened a case with EU support.

There is not much to be updated from my side.  It's been over three weeks and there is zero progress.

My server problem is of course not related to any wrong settings in MCadmin or firewall, as mentioned in some of the earlier posts by others in this thread.   My problematic server is a demo/test server that's been up for over a year to test out new features and stability of v14.x. From the original v13.4 server, it has gone through upgrades to each and every new patch of v14.0.x & v14.1.x, and everything on Android Enterprise have been working fine. Not a single MCadmin or firewall settings need to be changed since its initial installation in v13.4, as I was quite sure all are fine with my experience of installing hundreds of MobiControl on-premises and cloud server instances in the past few years.  

Android Enterprise enrollment probably started having problem some two three months ago.  I originally thought there are some glitches with new updates from Google server or support services, which happen many times in the last 12-18 months, and therefore did not pay much attention to it and thought that the enrollment should get back to normal soon.  It was not until v14.2.3 and v14.3 that include features I was very excited about that I decided to look more deeply.  I had located error messages mentioning about "empty token" from the server logs about 5 weeks ago and decided that I had to work with Soti support to seriously look into the problem.

As the Managed Google Play account, all related app-catalog rules and all server/firewall settings  were created a year ago  and have been working for so many different versions earlier,  I am quite sure the problem comes from buggy codes from v14.2.x installation file.  While I can go to Google portal to add more apps with the MGA account or change/add apps for app-catalog rules associated with the MGA account,  I cannot enrol new device, delete the app catalog rules or delete/add binding of any MGA account.  Any attempt to open and manage Managed Google Play apps within MobiControl web-console (a new feature) reports "data temporarily unavailable" error.  All the symptoms together convince me that some database tables are either corrupted or not compatible with the code logic.

Unfortunately, there is no progress even though I let Soti support team freely test  their device on my problematic server, web-console, and server logs over 3 weeks ago.   I only heard about stupid questions from some Soti frontline support, and have been denied access and direct contact to backend experts in the headquarters.  As there seems to have many posts (and hence many customers) having similar problem,  I hope the buggy codes  hidden somewhere won't affect my corporate/governmental customers with thousands of production devices in the very near future, and no one will regret why not grabbing hold of the case in my demo server to timely prevent disasters in big production servers worldwide.    I hope the way how my support case has been handled need not be further escalated further to Soti top management.

Soti has finally solved our "empty token" problem by making some updates on the license server on their side.  On our server, nothing was changed with our license reg-code, nor with any of the existing MGP account, and associated add-devices rule and app-catalog rules.  We can have a device enrolled with the old enrollment ID and managed app deployed to the device with no problem now.

Glad you got it solved.

Would be nice to find out what was really done on their side. Soti support told me it's because all my ports are not opened, but I think they didn't read my case...

Hi All,

Just to say our issue was two-fold in the end.

My DMA was incorrect, the devices were trying to use the internal FQDN which they could not resolve when connected to the outside world.  Changing this to the FQDN they use for DS access was part one of the fix.

Secondly, it transpired we had other 443 inbound blocking rules on our firewall which were being matched which took us a while to notice (once we started logging the right rules!).  Sorting our rule base out so it allowed 443 inbound to the SOTI server before blocking it otherwise fixed the inbound 443 connectivity issues.

Sounds like Raymonds issue was very different, for us there was no issue with the SOTI service rather inbound connectivity was not correctly configured.  I always suspected that to be the case.

Once more apologies for hijacking this post earlier, just hope this helps someone down the line.

Paul

Apparently, the empty token issue fix (related to reg code done on Soti license server side) was mentioned in the article

       https://discussions.soti.net/kb/empty_token-error-is-being-displayed

dated back to 4 April 2018.  It was so old that Soti support team had also forgotten about it  and had wasted over a month to come up with a fix published 11 months ago. 

It is also strange that my server (including the reg code) had no problem (though sequence of 14.0.x & 14.1.x upgrades in Q2-Q4 of 2018) till a v14.2.x upgrade done in last Dec/Jan.  Shouldn't the problem have been eliminated from happening due to buggy installation file codes and/or in Soti license server 7-8 months after the fix is known? 

Edgar Gomez  have solution the issue ? 

Thank you.

The solution we found for on premise server was to set the Device Management Address , in MCAdmin, to a public IP or FQDN. That is, the web console has to be accessible from internet.

Hi guys, 

the last post on this topic was some time ago but I want to share the solution which helped us.

Our problem was the proxy configuration in the Soti MobiControl webconsole. If we deactivated the proxy, the Managed Google Play account activation was successful. So if we activated the proxy and added our exceptions, we encountered problems with other services like the licensing service didn't work. 

In the end we added the proxy server in the hosts file of the DMZ Windows server and deleted the exception in the Soti MobiControl webconsole for the Soti server. I think the name was activate2.soti.net or something like that. The name was present in the Deployment Server Extensions verbose log. So all services are running correctly. 

In addition if you enter the proxy server settings, I had to re-enter the password for the proxy account every time. If I didn't enter the password every time I opened the proxy server settings, the empty password value will be used and authentification will fail.

Maybe this solution will help someone.

Hello Josky, 

Although I do not see a response from you on this topic, thank you for requesting a response from SOTI Support Staff.

As this post has been resolved, it is locked to further responses. 

If you are experiencing the same circumstances and the solution provided in this post is not working for you as expected, please create a new post.  We would love to hear about the details of your situation in order for the community to provide you some assistance and suggestions on route to a solution. 

Regards,