Edge 86.0.622.58 On-premises Sync Not Working Over VPN With Cached Local Login

Brass Contributor
We are running Edge 86.0.622.58 on Win10 Enterprise 1909 domain joined systems.


We are trying to configure the Edge GPO to enable local sync of favorites, but we are unable to get the on-prem sign-in to work over VPN and so the local profile.pb is never created.


Our settings are as follows:


BrowserSignin = 1

ConfigureOnPremisesAccountAutoSignIn = 1

RoamingProfileSupportEnabled = 1

SyncDisabled = 0


When we login to Windows 10 with a cached credential, connect to VPN, and launch Edge with these settings, we get prompted to sign-in.  The only account that seems to work is the "work or school account" which is our O365 email address.  Signing in using this account results in the Edge account type and sync account type as AAD instead of on-prem and the message "sync isn't available for this account"


I believe the cause of the issue is the AD account is not being used to sign in to the browser even though ConfigureOnPremisesAccountAutoSignIn is set to 1.  Doing a whoami at a command prompt shows my account name in domain\username format.


Using these same settings while logged into an on-site workstation results in on-premises sign in and sync working properly.  Is there any reason why this functionality would not work on a cached local logon/VPN scenario?



25 Replies

@jdbst56  Hi Joshua!  Thanks for reaching out!  The Identity Team was looking over your post and it would be helpful to get logs to better understand your specific question/scenario.  


Because of the sensitive information/PII that can be in the logs, there are a couple of options: 

  • File a customer support request  You should be able to work with them directly to investigate/resolve your specific issue.  
  • Submit diagnostic data through our in-browser feedback tool. It's under "..." menu > Help and feedback > Send feedback.   You need to turn on "Send diagnostic data" and this should capture all the necessary logs.

If you are planning to use the in-browser feedback tool please get into a clean state and log feedback only after the issue is reproduced.  You can get into a clean state by 1) deleting User Data folder before launch OR 2) Create a separate folder and launching edge from command line using --user-data-dir=<that folder>


Additionally, to help the team find your feedback quickly, you can include the string "ForumIdentityOnPremisesVPN" and comment below once you've submitted it.  



I have a similar issue. Seems that some VLANs work as expedted, others automatically want me to sign in using an Azure AD account.

@Kelly_Y Hello, I have submitted the logs through the in-browser feedback tool today per your rquest.

@jdbst56 Thank you for the feedback!  I've located your specific report and routed it to the Identity Team.  We will follow up if there is any additional information needed or updates/insights to share.  



@jdbst56 The team has investigated and can see from the feedback report submitted, on MS Edge launch, the user got signed in with the secondary AAD account on the machine.


ConfigureOnPremisesAccountAutoSignIn policy mentions that MS Edge will give preference to AAD accounts over on-premises account.


Enable the use of Active Directory accounts for automatic sign in if your users' machines are Domain Joined and your environment is not hybrid joined


The behavior currently being experienced is to be expected and the change to use secondary account was made in MS Edge V86.  


The current suggestion from the team is to consider removing the secondary AAD account from machine.


To provide a little more information, we are evaluating/investigating creating a new policy so users will not get implicit sign-in with secondary AAD account if ConfigureOnPremisesAccountAutoSignIn is configured.  


@bin_da - Please take a look at this post and see if it helps your situation as well.  





@Kelly_Y Thanks for your response.


So in our testing we saw that both AAD accounts and personal accounts are taking precedence over the on-premise AD account.  We had to remove all traces of both accounts in order for the AD sync to work.


In our testing scenario, we removed the AAD account from Access work or school in Windows 10.  After doing so and closing Edge, deleting the the User Data folder from AppData\Local\Microsoft\Edge and relaunching Edge, we found that the browser was then trying to sign in using personal gmail/hotmail accounts.  We're not certain where these logins were coming from possibly the Microsoft Store or other Microsoft resources.  On one system, signing out of all Microsoft resources and clearing the Edge User Data folder allowed the sign-in/sync using the AD account to work successfully.  On another system, signing out of all resources and clearing Edge User Data folder did not resolve the signing with personal account.  On this system we had to completely delete the Windows user profile to enable sign-in/sync with the on-premise AD account.


So in order to make this functionality viable for our enterprise, there needs to be the ability to force the sync to use on-premise AD account without the need of deleting the Edge User Data folder and/or Windows user profile.  

@jdbst56 Thanks for following up with your testing results!  The Identity Team has confirmed what you've seen is to be expected.  


The auto sign-in policy works in this way:

  1. First tries with Windows OS sign-in account.
  2. Then tries with secondary AAD account.
  3. Then tries with secondary MSA account.

In this case, once the AAD account was removed, step “3” took place.  So like you noticed it is necessary to remove all of the MSA and AAD accounts from settings.


We appreciate your feedback!  It is helpful to hear directly from users as they are investigating the new policy.  



@Kelly_Y  Do you have any timeframe for this:
"To provide a little more information, we are evaluating/investigating creating a new policy so users will not get implicit sign-in with secondary AAD account if ConfigureOnPremisesAccountAutoSignIn is configured."

@benhealy Hello!  Sorry, no ETA yet.  I can follow up here once we have updates to share.  :smile:


Is this blocking the adoption or deployment of MS Edge in your organization?  



@Kelly_Y Yes it is stopping us deploying currently.


Our Windows 10 devices are hybrid joined and our Security/Architecture team are not endorsing cloud sync. As On-Premises sync doesn't work with this setup, if we roll out our users will be forced to export and import their bookmarks whenever they log into a new computer or get re-imaged. Not as user friendly as they are used to with Favourites and folder redirection.

@benhealy Thank you!  I've passed this information on to the team.  



@Kelly_Y  Hi, Do you have any update on when we can expect a new GPO setting to force on-prem account sign-in?

@jdbst56 Hi!  Still no ETA but we’ll keep you updated when we know more!  Thanks!




"The current suggestion from the team is to consider removing the secondary AAD account from machine."

how? :)

Our machines are not hybrid joined - we also see this behaviour (Edge not recognizing on-prem sync) even on Servers not having Office 365 installed. 



Hello, do you have any update ? :)

@So_224 Hi!  No updates from the team yet but we will follow up here with information.  Thanks!




Is there any news on this subject? 


Do you have any update? We would really like to move to Edge as the default browser for our organization but the inability to locally sync favorites is preventing us from doing so. Perhaps Microsoft should consider using Chrome's implementation of RoamingProfileSupportEnabled which does not require any browser sign-in. The ability to simply redirect the profile.pb file to a network share such as the user's home drive would be sufficient for our purposes.
@Kelly_Y it's been 2 months since your last reply to this post and 4 months since it was opened. Are there any updates on this issue?