One of the new features in MS Edge v85 is support for roaming profile settings to a local file, profile.pb.
This is great news for many organizations that cannot synchronize the user settings to Azure AD account due to for example laws, compliance or lack of Azure AD Premium. More information about the new feature in Edge version 85 can be found here: https://docs.microsoft.com/en-us/DeployEdge/microsoft-edge-on-premises-sync
I wrote a blog post about two years ago on how to roam the “Profile.pb” file in Google Chrome using UE-V here: https://ccmexec.com/2018/09/using-google-chrome-roaming-profile-settings-with-ue-v/
Tested using UE-V for the new MS Edge feature and it works fine as well! The short video below shows two computers with the same user logged on to both and roaming favorites between them.
The new setting enables the creation of the “Profile.pb file” Note that Edge and Edge Beta saves the file in different locations per default which makes sense. The default location can be changed as well using a Group Policy as well if we want to point it to another folder. For MS Edge Beta the default folder is shown below.
To enable roaming using the local file we need to enable two Group Policies. “Configure automatic sign in with an Active Directory domain account when there is no Azure AD domain account” as shown below.
NOTE: as the name indicates it will not work if the user exists in AzureAD in a Hybrid setup.
And then then we enable the creation of the profile.pb file by using the “Enable using roaming copies for Microsoft Edge profile data” as shown below.
If we look in MS Edge settings on the client we can see that the setting is applied.
I have posted the UE-V xml template for MS Edge beta as Edge Stable v.85 is not released when I write this post on Github here: https://github.com/Ccmexec/Other/tree/master/UE-V%20sample%20files
Because the Edge Beta and Edge Stable saves the files in different locations I have created one for Beta and will post the one for Stable when it is released.
The content of the file is really simple as shown below.
<?xml version="1.0"?>
<SettingsLocationTemplate xmlns="http://schemas.microsoft.com/UserExperienceVirtualization/2013A/SettingsLocationTemplate">
<Name>MSEdgeBeta</Name>
<ID>EdgeBeta-Profile</ID>
<Version>1</Version>
<Author>
<Name>Jorgen</Name>
<Email>jorgen@ccmexec.com</Email>
</Author>
<Processes>
<Process>
<Filename>MSEdge.exe</Filename>
</Process>
</Processes>
<Settings>
<File>
<Root>
<EnvironmentVariable>APPDATA</EnvironmentVariable>
</Root>
<Path>Microsoft\Edge Beta\User Data</Path>
<FileMask>profile.pb</FileMask>
</File>
</Settings>
</SettingsLocationTemplate>
In my case I simply drop the template in my UE-V template folder and the clients will pick it up and start syncing the file.
The new roaming option is great news for many organisations and if we combine it with UE-V the end user experience is really great!
Thanks for this info!
Do you also know if and how we can roam History and Cookies?
According to Docs it is coming.
Regards,
Jörgen
Test
Hi Jörgen
Thanks for the reply. Can you possible share a link to the docs you are referring?
Greetings,
Joris
It is actually in the screenshot above as well, under History “Coming Soon-“
does using the profile.qb imply any security or performance caveat
Hi,
I would say no, the file is really small and security is not worse than using the registry.
Hello,
Thank you very much for this post.
It’s working for me, but like you i can’t give to my users the possibility to sync Passwords for example. It’s greyed out, and it’s wrote “it’s managed by your organization”.
Do you know how to resolve activate password sync ?
Thanks in advance.
Best regards,
Taoufik.
Hi, it is not possible to Synchronize password to the local roaming profile that is why it is blocked. I can think of many reasons, security for once, saving password in Chrome/Edge is not recommended.
Regards,
Jörgen
Have you seen a consistent user experience with the Edge roaming profile setting?
I started piloting it to with existing devices and there were a lot of differences in the user experience. If people already had profiles set up it would frequently not create the Domain\%username% account.
Or it would create the account but it wouldn’t be marked as default so no one would see it.