Chromium Edge: Issues With User Data Directory
Joao Charlesbois
Policies for modifying data directory paths (For example, configuring the UserDataDir or DownloadDirectory support variables). When configuring these policies, you can use variables instead of hard-coded paths. For example, to store your profile data under user local application data on Windows instead of the default location. Set the UserDataDir policy to $local_app_data\Edge\Profile. On most Windows 10 installations, this path resolves to C:\Users\\AppData\Local\Microsoft\Edge\Profile.
[German]The Chromium Edge browser has nasty problems in the corporate environment when managing a user data directory. When user data directories are enabled, the Chromium Edge cannot be used by the same user on different clients at the same time.
German blog reader Christian S. notified me about this problem with the user data directories on the Chromium Edge at the end of January 2020. I'm going to post it here in the blog to discuss the issue.
Actually a nice idea that might allow a user to use Edge on different clients with his stored data via his account. That's the theory, but it doesn't work in practice. Christian told me: Unfortunately there is also a problem with the Edge once the user data directory is configured.
Because the Edge only runs on one client when the user data directory is created. After setting up a user data directory using the Edge group policies (see figure above), Christian made the following observation with the Chromium Edge.
So the user data directory is blocked on the second workstation by the Edge running on the first workstation. The Edge Browser is then no longer usable. Instead, the running instance at the first workstation must be explicitly terminated to be able to use the Edge on the second system.
I'm using C# / Selenium 3 to launch and control instances of Edge (Chromium). One of the requirements I have is that any instance of Edge launched by my code should use the default profile (The one that Edge uses if you open it normally). I can do this with one instance of Edge by using the user-data-dir argument. But if I try to launch another instance then I get an several errors in the new web driver window (Access is denied, Unable to create Cache, Error reading broker pipe: The pipe has been ended). I'm guessing the user-data-dir is in use by the first instance. Do I need to create a copy of the profile some how?
You got the issue because the same user-data-dir path is configured for both instances. The user-data directory will get locked by the first instance and the second instance will fail with exception as the directory is in use. You should avoid starting Edge WebDriver instances with the same user-data-dir at the same time.
If you don't need the first Edge WebDriver instance anymore, you can close it with driver.Quit(), then you can start the second instance with the same user-data-dir path. Please remember that it's a good practice to close the WebDriver instance when you finish using it.
What you can do is1. Copy your current User Data folder (with said guest profile) to a NEW DIRECTORY2. Point chrome shortcut to the NEW DIRECTORY using the --user-data-dir parameter3. After launch, notice that the profile is exactly as the original. Now modify this chrome instance, removing profiles and things you don't need.
The --user-data-dir flag allows you to specify a custom location for the user data directory, which stores information such as your browser history, bookmarks, and extensions. This can be useful if you want to create a separate profile for testing purposes or if you are encountering issues with the default user data directory.
The --profile-directory flag allows you to specify a custom directory name for a new profile within the user data directory. This can be useful if you want to create multiple profiles with different settings or configurations for testing or troubleshooting purposes.
This will create a new profile named TestProfile within the user data directory located at c:\temp\TestEdgeUser, or load an existing profile with that name if it already exists. You can use any directory name you like and specify any custom location for the user data directory using the --user-data-dir flag.
The --do-not-de-elevate flag disables a feature in Microsoft Edge that automatically relaunches the browser as a non-administrator (running at Medium IL instead of High) if it was launched with administrator privileges. By using this flag, you can prevent Edge from silently de-elevating itself and instead display a warning to the user, helping them recognize that the browser is running with elevated privileges. This can be useful for developers or IT professionals who need to troubleshoot issues with the browser while running it as an administrator, as it allows them to run Edge with elevated privileges without automatically de-elevating the process.
Launching Edge with the --inprivate flag opens a new browser window with InPrivate mode activated by default. In this mode, Edge does not save any browsing history, cookies, site data, or information entered in forms. Temporary files and other browsing data are deleted after the InPrivate window is closed. This feature is especially useful when you are using a shared or public computer and do not want your browsing activity to be traceable by other users.
I guess this would also apply to Google Chrome since both platforms are so similar. Wondering if anyone out there is testing/piloting Edge Chrome? We do not have Azure AD or Office 365... I'm trying to decide a best way to deal with users that play musical chairs and have a consistent experience. We use roaming profiles in our environment with redirected Documents and Appdata folders to a network location.
Since we don't use enterprise Microsoft cloud products, we don't have "business" MS accounts for our email domain to be able to sign in as a business user. I see three possibilities:
I've read bad things can happen with Google Chrome with a chrome profile under a roaming app data folder, particularly if workstations have differing versions of Chrome and also that Chrome puts massive amounts of data to the profile leading to a slow windows login with roaming appdata, but I've heard mixed things about whether that holds true for when Roaming Appdata is redirected to the network. Also, I have found nothing conclusive as to whether Edge Chrome has the same issues as Google Chrome regarding roaming Appdata... this is one area that the GPO sets are different on the two platforms. Edge Chrome seems to have fewer options around profile location and behavior.
Hey there, I'm still kind of beating my head against the wall on this one. I think a lot of people are, this thread figures high in google results.
Unfortunately, to the first responder, not using roaming windows profiles is not an option for me.
To TheServerBoy, is your envirnment just a regular on-prem AD? I have all of those options enabled the way you do, and Edge Chrome STILL insists on writing the profile and user data to local appdata. Are you redirecting your roaming appdata to a network location or no? (we redirect roaming appdata and basically every uer folder that can be redirected to a network folder).
My other issue is sync. It works fine up until the user encounters a problem with their local windows profile copy and I have to delete the local windows profile copy from the workstation. You would think at that point the next time the user signs into their workstation a windows profile would then come down from the server and all would be good. However, at that point, for us at least, Edge becomes broken and no longer allows the user to sign into the browser (if you click sign in, it hesitates for a moment then does nothing). The only "fix" is to also delete the server copy of the user's windows profile which is not good for the user because then they are basically starting over as a new user.
The override happens in chrome/app/chrome_main_delegate.cc. Platforms not building with the file may not have implemented the override. Overriding the user data directory via the command line is not supported on iOS.
Chrome Remote Desktop (CRD) used to set $CHROME_USER_DATA_DIR or $CHROME_CONFIG_HOME on the virtual session on a Linux host, since a single Chrome instance cannot show windows on multiple X displays, and two running Chrome instances cannot share the same user data directory. However, with the obsolescence of dbus-x11, most modern Linux distros have lost the ability to simultaneously run multiple graphical sessions for the same user without running into difficult-to-trace dbus cross talk issues, and Chrome can only be run on a single X display per user in reality. Therefore, CRD no longer sets these environment variables for new installations after CRD host M105.
When executing web automation with Chrome/Edge/Firefox browsers in the child session of a PictureInPicture (PiP) mode and you want to continue using the browser in the main session, please know that both Chrome and Edge cannot be launched simultaneously, in different sessions, while using the same user data directory.
You want to execute the automation in PiP with the default user data folder since it contains your default profile and all your business apps login history and cookies. Set UserDataFolderMode to DefaultFolder . Please keep in mind that simply launching the browser in your working session will not be possible until the PiP automation finishes and/or the PiP browser stops.
The policy for modifying the user data directory and other paths for Chrome touse has support for several variables, so you don't need to set a hard-codedpath for all users. For example, if you want to store your profile data underthe user local application data on Windows, set the UserDataDir policy to :"$local_app_data\Chrome\Profile" Which on most Windows 7 / Vistainstallations would resolve to :C:\Users\CurrentUser\AppData\Chrome\Profile.
e2b47a7662