I note that launching Chrome with the '--user-data-dir=...' parameter *does* work.  It's just the registry/policy setting which is ignored or not parsed correctly.

We had a fix in M57 and M58 to ensure user data directory is set through GPO policy- https://bugs.chromium.org/p/chromium/issues/detail?id=700371.

Looping to few experts to respond about by manual regedit being not honored.

To clarify for my case, since it may be important:

- UserDataDir is set manually via regedit, not by Group Policy (we don't have AD)
- Chrome does not crash on launch, it just ignores our UserDataDir setting.

This is the issue then. Policies for Chrome are only respected if coming from GPO even if not in AD. Please use the local gpedit.msc to set the policies on the client. If you need to automate this you can also use a power shell script to set GPOs.

> Policies for Chrome are only respected if coming from GPO even if not in AD.

OK, that's clearly the issue and I suppose we'll have to deal with that.  Thanks.

Is there a simple reason for the change, out of interest?

This has been the behavior since at least 20 versions of Chrome. :)
I think the change was made to reduce the impact of malicious software changing the settings of the browser.

> This has been the behavior since at least 20 versions of Chrome. :)

No, no, definitely not!

Our locally-crafted hit for UserDataDir was working until the last few weeks.  One profile (in the custom location) shows 'Last Version' of 56.0.2924.87 so it was definitely working with that; another shows '57.0.2987.133' so it was working with that too.

Ah right. This policy is an exception because it is needed so early that it uses its own policy reading code. 

There were recently changes to the code there but this should not have changed the behavior.

I will reopen the bug for now.

For information, the output of "chrome://policy" (which I've just discovered)

Applies to   Level     Source    Policy name  Policy value    Status
Machine      Mandatory Platform  UserDataDir  Hide value      OK

${roaming_app_data}\Google\Chrome\User Data

So Chrome certainly thinks this policy applies, but it is as I've described being ignored.  This is Chrome 58.0.3029.96 (64-bit).

I thought we specifically tested this. I'll take a look.

Hi, I'm not able to reproduce this not working. I tried two tests:
- HKLM\Software\Policies\Google\Chrome\UserDataDir to "${roaming_app_data}\Google\Chrome\User Data"
- HKCU\Software\Policies\Google\Chrome\UserDataDir to "c:\tmp\${user_name}\zippy"

In both cases, it seems to work as expected. I tried this on Win10, but I don't think it should matter. 

I also tried 58 Stable x64, and at HEAD x86.

Can we identify anything more specific about the config?

When manually editing HKLM using regedit I've tried various fixed paths in HKLM\...\UserDataDir

Local drive c:\cache\chrome - not honoured
Network drive h:\cache\chrome - not honoured

In both cases the given path appears in the output of "chrome://policy" with Status OK.  In both cases the running Chrome uses the default location inside %LOCALAPPDATA% instead.

As I said, this has been achieved using manual registry edits (scripted to all PCs[*]) because we don't have AD.  However if I use gpedit.msc with chrome.adm instead the values I include seem to be correctly honoured.

So the previous comment "Policies for Chrome are only respected if coming from GPO even if not in AD." appears to be correct?  [In which case it seems that the output of "chrome://policy" is misleading if it's actually ignoring the policies it's claiming are active!]

Is this the intended behaviour?  Given that the end result of GPO deployment is just "some value in the registry", this is unfortunate if such a distinction means it won't work for me.

[*] Essentially just "regedit /s ..." with a target REG referring to HKLM.

In our case we fixed this by, as an earlier comment suggested, deploying this via local group policy rather than a manual/scripted registry edit.  Given lack of follow-up comments, I'm assuming this is the intended behaviour and this bug can be closed.

Hi, sorry for the delay. To my knowledge there's no reason you should have to use a local group policy (in fact, I was testing with a manual registry key) but I wasn't able to reproduce the problem that you reported.

Was just about to respond to the now-deleted comment 15, but will ignore that since the poster may have posted incorrect information.

For full config & disclosure here: our setup is:

- Windows 7 PCs
- Domain-joined to a Samba-without-AD domain
- Local group policy scripted/managed on each PC
- 'Manual' registry hits scripted centrally

With a manual registry edit, the value stopped being honoured after around Chrome 56/57.  After this time a local policy object was required.  In all cases, the content of HKLM\Software\Policies\Google\Chrome\UserDataDir appears the same.

I found this thread while following up on a post I made regarding the same behavior in April with no resolution. https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome-admins/WegbXSZFISk/C-YMJLzSBAAJ 

As of V59 this is still not working with the GPO ADM pushed in AD.  Chrome://policy will show the policy is applied and correct but Chrome://version will show the actual profile path to be the default local.

Windows2008R2standard
Domain-Joined to AD domain
GPO to set userdatadir to unc path