Sync issues

New Contributor

I can't get sync to work in our Amazon Workspace environment (running Server 2016). Sign in authenticates fine but then I get an error saying "Hmm...we're having trouble verifying your account details." and a prompt to sign in. 


I am have Seamless SSO enable which works fine for all other apps.


Has anyone got any ideas as to where I can start troubleshooting?

5 Replies

Is anyone able to help?


Looking at sync-internals I get the following information:


Disable Reason: Waiting for sync url

Last token error: EDGE_AUTH_ERROR: 3, 24, 4b0

I have this same problem on a Windows Server 2016 RDS session host deployment, we have Azure AD connect with Seamless SSO configured, SSO is working fine for all other Azure AD applications. 


You get prompted to sign in, SSO signin appears to be successful, but sync stays in the "setting up sync" phase indefinitely. 


This is problematic because favorites are not stored in a part of the roaming profile, so users favorites appear to have been lost from the users' perspective unless the session broker load balancing happens to route them back to the same session host they were logged in to when they created their favorites.



edge://sync-internals shows:


Transport StateDisabled
Disable ReasonsWaiting for sync url
Sync Feature Enabledfalse
Setup In Progressfalse
Auth ErrorOK since browser startup
Sync Account TypeAAD



Requested Token2020-03-24 12:20:00 -04
Received Token Response2020-03-24 12:20:00 -04
Last Token Request ResultOK
Has Tokenfalse
Next Token Request2020-03-24 12:20:07 -04
Last Token ErrorEDGE_AUTH_ERROR: 3, 24, 4b0






I haven't been able to resolve the issue. If I sign in using the beta or Dev channel then I the additional error:


"We are unable to verify your account. Please sign in for account_hint"


Most but not all of my users get this error but I can't see any differences.



I'm going to open a support case on it, will keep you updated on if I get a resolution.


I wound up doing various tests.. stand up a new host in it's own collection in an OU where inheritance was blocked to rule out something in group policy breaking it.


I was able to reproduce it with no GPOs linked.


It turned out the culprit was Symantec Endpoint Protection.

The servers were on the most current version but apparently there is an incompatibility.


After uninstalling Symantec Endpoint Protection it works fine.