• If set, the Chrome settings will not expose the option to enable crostini unless the enable-experimental-kernel-vm-support flag is set in chrome://flags ↪-kiosk ⊗: Enable kiosk mode. Please note this is not Chrome OS kiosk mode. ↪-kiosk-printing ⊗: Enable automatically pressing the.
• This thread is locked. You can follow the question or vote as helpful, but you cannot reply to this thread.
• @Hitesh No, it is still unavailable. Although you will never get the amount of customization in Chrome that you will have with about:config in Firefox, Chrome://flags might be of use in Chrome.

• Chrome Configurator
• Chrome Config
• Google Chrome Settings
• Chrome Configuration Profile Mac
• Chrome Config Settings

From inthecloud247.com (Peter Klapwijk)

Google Chrome can be managed using a custom configuration policy for Windows 10. The policy consists of two parts. The first part is used to deploy the Chrome ADMX file to the Intune managed device. The second part of the policy is used to manage the settings of choice.

Google Chrome can be managed using a custom configuration policy for Windows 10. The policy consists of two parts. The policy consists of two parts. The first part is used to deploy the Chrome ADMX file to the Intune managed device.

Deploy the Chrome ADMX file

The Chrome ADMX file can be downloaded as part Chrome Enterprise bundle. After downloading the bundle, locate the ADMX file and open the file with a text editor.

Now open a browser to sign-in to the Microsoft Intune portal.

• Sign-in to the Device Management Portal
• Browse to Devices – Windows
• On the Configuration Profiles tab click Create profile

• Give the configuration profile a Name
• Enter a Description (optional)
• Choose Windows 10 as Platform
• Choose Custom as Profile type
• Click the Settings tab
• Click Add

With this row we deploy the ADMX file to the Windows 10 device. As you can see the OMA-URI contains ADMXInstall.
More info on how the OMA-URI is build up and complementing information about ADMX-backed policies can be read in this article on Microsoft Docs.

Enter below information to the policy;
Name: Chrome ADMX Ingestion
OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx
Data Type: String
Value: As value copy the entire content of the ADMX file in the value field
Click OK twice and click Create.

The policy to deploy the ADMX file is ready. In the next steps we add the settings we manage with Intune to the same policy.

How to build up the OMA-URI

As with deploying the ADMX file, for the settings to manage we also need to know the OMA-URI which we need to use. But the OMA-URI for managing the settings consists of some information we need to collect ourselves from the Chrome ADMX file.

This is for example the OMA-URI to manage the Homepage Location
./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/HomepageLocation
Let`s split up the OMA-URI in seperate parts.
This is default for managing applications using an ADMX file:
./Device/Vendor/MSFT/Policy/Config/
The part that comes next is not always the same, we need to follow some rules:
/Chrome~Policy~googlechrome~Startup/
It start with Chrome (the ADMX file name), like in the ADMXInstall URI, followed by Policy. Between every part we have the ~ sign.
After Policy we see the name of two categories. These categories can be found in the Chrome ADMX file.
When we open the ADMX file in a text editor, we can see there are several categories. The first categorie we find in the ADMX file is the top category and as we can see that is googlechrome. We put this in the OMA-URI after Policy.

If we search for the actual policy we want to control, in this case HomepageLocation, we also find there is a category mentioned for that policy. It is the parentcategory of HomepageLocation, Startup.
So startup is the next part of our OMA-URI.

la

The last part of our OMA-URI is the actual policy displayname, in this case HomepageLocation. If we put al this information together, we have our OMA-URI.

Manage Startup, Home page and New Tab page settings

We start with managing the settings in the Startup, Home page en New Tab page section. These are things like controlling the Homepage Location and showing the Home Button.

We have already seen how to build the OMA-URI for the policy HomepageLocation, so let`s start with that one. The Data type for these settings is always String. Than we only need to know what our Value is.

The value starts with <enabled/> (or <disabled/> if you like to disable a setting).
If we have a setting which can only be set to enabled or disabled, than that`s the value.

But for Homepage Location, we need to set the actual homepage location. In this case <enabled/> is followed by a data id. The data id is found again in the ADMX file, in below example the text id, HomepageLocation.
And as last we need to set a value, the valuename. This is the homepagelocation (which needs to start with http/https, information which you can fine when running GPeditor).

Switch over to the Intune portal.

• Open your existing custom policy or create a new policy
• On the settings tab click Add
• Give the Row a Name
• Fill in the OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/HomepageLocation
• Data type: String
• Value:

• Click OK

That`s it! We have managed our first Google Chrome setting using Microsoft Intune.

The next example is the Homepage Is New Tab Page policy. Open the Chrome ADMX file and search for HomepageIsNewTabPage. With the information found in the ADMX file we can create the OMA-URI. As you can see in the screenshot we only have the option to enable or disable the policy, no id or value. I set the policy to disabled.

Switch to the Intune portal and add a new row to the custom policy.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/HomepageIsNewTabPage
• Data type: String
• Value: <disabled/>

I want to show the Home Button in the Chrome browser. In the ADMX file we can see again we have only the options to enable or disable the setting.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/ShowHomeButton
• Data type: String
• Value: <enabled/>

The next thing I want to control is the startup behavior. I want a website to open when Chrome is started. This can be achieved by setting the Restore On Startup to load a website (or multiple) and specifying a URL. But the solution consists of two policies.
The first one is RestoreOnStartup.

If we take a look at the ADMX file we see there are multiple options to configure, which are corresponding to numbers. If we want to show a website on startup, we need to set the value to 4.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/RestoreOnStartup
• Data type: String
• Value:

The next setting is to specify one or multiple URLs to show on startup, which is done with the policy RestoreOnStartupURLs.
Have a look at list id, this time the id is not similar to the policy name.

The value for this policy is not just a URL, like it was the case with HomepageLocation. Because you can specify multiple URLs in the policy, the URLs need to be separated with the (encoded) unicode character &#xF000, like it is also the case with managing some setting for Internet Explorer. The URLs also need to be numbered, 1,2,3 etc even if you only specify one URL.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Startup/RestoreOnStartupURLs
• Data type: String
• Value:

Manage the Password Manager

We have seen some examples in the Startup, Home Page and New Page Tab settings category, let`s move to another catagorie; PasswordManager.

By reading the article this far, you probably now know to get the required information from the Chrome ADMX file. But for those of you who just found the article to manage the Password Manager in Chrome, just have another look at the information in the ADMX file.
The policyname is PassWordManagerEnabled. The parent category, which we also need in the OMA-URI, is PasswordManager. As we can see, we can only enable or disable the Password Manager.

Now switch back to the Intune portal to add a new row for the Password Manager policy.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~PasswordManager/PasswordManagerEnabled
• Data type: String
• Value: <disabled/>

This is the only setting I want to manage in the Password Manager category, let`s move to another interesting category; Extensions.

Manage Google Chrome Extensions

The last category I want to discuss here is extensions. In Google Chrome we can add several extensions to the browser with several functions like the Windows Defender Browser Protection and Windows 10 Accounts extensions.

Chrome Configurator

I want the two mentioned extension to be installed automatically, which can be achieved by using the policy Configure the list of force-installed apps and extensions (ExtensionInstallForcelist).
Let`s skip the info from the ADMX file this time, but let`s have a look at the policy via Gpedit. Here we find info how this is done with the GPO, using the custom policy we do something similar.
In the GPO we need to specify the extension id followed by the Chrome webstore update URL https://clients2.google.com/service/update2/crx. using Intune we also need the extension id and use the webstore url.

The extension id can be found by looking up the extension in the Chrome webstore. The extension id can be found in the url.

The extension id followed by the URL is ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx for the Windows 10 Accounts extension. Every extension needs to be separated again with the (encoded) unicode character &#xF000 and because we need to number the extensions, the unicode character is also used between the number and the extension string. For two extensions the value is like below example.

• Open your existing custom policy or create a new policy
• On the settings tab click Add
• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallForcelist
• Data type: String
• Value:

As I want to be in full control which extensions are used, I want to block all extensions besides the extensions I force to install. This can be achieved by using an extension blacklist. To block all extensions we need to add * to the blacklist, like we would do by using the GPO. The * needs to be specified in the value section of the custom policy.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallBlacklist
• Data type: String
• Value:

And last I will whitelist the two extension which I force to install using the force install policy setting.
In the value of this setting we need to specify the extension id, number the extension ids and separated them by the unicode character.

• Give the Row a Name
• OMA-URI: ./Device/Vendor/MSFT/Policy/Config/Chrome~Policy~googlechrome~Extensions/ExtensionInstallWhitelist
• Data type: String
• Value:

The extensions are in control by these policies.

End-user experience

Let`s have a look at the end-user experience.
When we logon to an Intune managed Windows 10 device, open the Chrome browser and click on the three dots in te right top, the menu is shown. At the bottom a message is shown Managed by your organization.

When we open the settings of the browser, we can see the deployed policies are indeed applied. For example the Show home button setting is enabled and marked with a building icon.

Enter chrome://policy in the address bar of the Chrome browser to see a complete list of applied settings.

And if we open the extensions section, we can see the two forced extensions are installed en we cannot switch them off.

That`s it for this time. I hope you find the post informative and helps you to manage the Chrome web browser using Microsoft Intune.

A related post about managing Google Update setting with Intune can be found here.

:rotating_light: Important

Please file issues on the repo for the new js-debug extension. By default, this extension now delegates to that one which is built-in to VS Code.

Debug your JavaScript code running in Google Chrome from VS Code.

A VS Code extension to debug your JavaScript code in the Google Chrome browser, or other targets that support the Chrome DevTools Protocol.

Supported features

• Setting breakpoints, including in source files when source maps are enabled
• Stepping, including with the buttons on the Chrome page
• The Locals pane
• Debugging eval scripts, script tags, and scripts that are added dynamically
• Watches
• Console

Unsupported scenarios

• Debugging web workers
• Debugging Chrome extensions
• Any features that aren't script debugging

Getting Started

1. Open the folder containing the project you want to work on.

Using the debugger

When your launch config is set up, you can debug your project. Pick a launch config from the dropdown on the Debug pane in Code. Press the play button or F5 to start.

Configuration

The extension operates in two modes - it can launch an instance of Chrome navigated to your app, or it can attach to a running instance of Chrome. Both modes requires you to be serving your web application from local web server, which is started from either a VS Code task or from your command-line. Using the url parameter you simply tell VS Code which URL to either open or launch in Chrome.

Just like when using the Node debugger, you configure these modes with a .vscode/launch.json file in the root directory of your project. You can create this file manually, or Code will create one for you if you try to run your project, and it doesn't exist yet.

Tip: See recipes for debugging different frameworks here: https://github.com/Microsoft/vscode-recipes

Launch

Two example launch.json configs with 'request': 'launch'. You must specify either file or url to launch Chrome against a local file or a url. If you use a url, set webRoot to the directory that files are served from. This can be either an absolute path or a path using ${workspaceFolder} (the folder open in Code). webRoot is used to resolve urls (like 'http://localhost/app.js') to a file on disk (like /Users/me/project/app.js), so be careful that it's set correctly.

If you want to use a different installation of Chrome, you can also set the runtimeExecutable field with a path to the Chrome app.

Attach

With 'request': 'attach', you must launch Chrome with remote debugging enabled in order for the extension to attach to it. Here's how to do that:

Windows

• Right click the Chrome shortcut, and select properties
• In the 'target' field, append --remote-debugging-port=9222
• Or in a command prompt, execute <path to chrome>/chrome.exe --remote-debugging-port=9222

macOS

• In a terminal, execute /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --remote-debugging-port=9222

Linux

• In a terminal, launch google-chrome --remote-debugging-port=9222

If you have another instance of Chrome running and don't want to restart it, you can run the new instance under a separate user profile with the --user-data-dir option. Example: --user-data-dir=/tmp/chrome-debug. This is the same as using the userDataDir option in a launch-type config.

Launch Chrome and navigate to your page.

An example launch.json file for an 'attach' config.

Chrome user profile note (Cannot connect to the target: connect ECONNREFUSED)

Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use the userDataDir launch config field to override or disable this. If you are using the runtimeExecutable field, this isn't enabled by default, but you can forcibly enable it with 'userDataDir': true.

If you are using an attach config, make sure you close other running instances of Chrome before launching a new one with --remote-debugging-port. Or, use a new profile with the --user-data-dir flag yourself.

For other troubleshooting tips for this error, see below.

Errors from chrome-error://chromewebdata

If you see errors with a location like chrome-error://chromewebdata/ in the error stack, these errors are not from the extension or from your app - they are usually a sign that Chrome was not able to load your app.

When you see these errors, first check whether Chrome was able to load your app. Does Chrome say 'This site can't be reached' or something similar? You must start your own server to run your app. Double-check that your server is running, and that the url and port are configured correctly.

Other targets

You can also theoretically attach to other targets that support the same Chrome Debugging protocol, such as Electron or Cordova. These aren't officially supported, but should work with basically the same steps. You can use a launch config by setting 'runtimeExecutable' to a program or script to launch, or an attach config to attach to a process that's already running. If Code can't find the target, you can always verify that it is actually available by navigating to http://localhost:<port>/json in a browser. If you get a response with a bunch of JSON, and can find your target page in that JSON, then the target should be available to this extension.

Chrome Config

Examples

See our wiki page for some configured example apps: Examples

Other optional launch config fields

• trace: When true, the adapter logs its own diagnostic info to a file. The file path will be printed in the Debug Console. This is often useful info to include when filing an issue on GitHub. If you set it to 'verbose', it will also log to the console.
• runtimeExecutable: Workspace relative or absolute path to the runtime executable to be used. If not specified, Chrome will be used from the default install location.
• runtimeArgs: Optional arguments passed to the runtime executable.
• env: Optional dictionary of environment key/value pairs.
• cwd: Optional working directory for the runtime executable.
• userDataDir: Normally, if Chrome is already running when you start debugging with a launch config, then the new instance won't start in remote debugging mode. So by default, the extension launches Chrome with a separate user profile in a temp folder. Use this option to set a different path to use, or set to false to launch with your default user profile.
• url: On a 'launch' config, it will launch Chrome at this URL.
• urlFilter: On an 'attach' config, or a 'launch' config with no 'url' set, search for a page with this url and attach to it. It can also contain wildcards, for example, 'localhost:*/app' will match either 'http://localhost:123/app' or 'http://localhost:456/app', but not 'https://stackoverflow.com'.
• targetTypes: On an 'attach' config, or a 'launch' config with no 'url' set, set a list of acceptable target types from the default ['page']. For example, if you are attaching to an Electron app, you might want to set this to ['page', 'webview']. A value of null disables filtering by target type.
• sourceMaps: By default, the adapter will use sourcemaps and your original sources whenever possible. You can disable this by setting sourceMaps to false.
• pathMapping: This property takes a mapping of URL paths to local paths, to give you more flexibility in how URLs are resolved to local files. 'webRoot': '${workspaceFolder}' is just shorthand for a pathMapping like { '/': '${workspaceFolder}' }.
• smartStep: Automatically steps over code that doesn't map to source files. Especially useful for debugging with async/await.
• disableNetworkCache: If false, the network cache will be NOT disabled. It is disabled by default.
• showAsyncStacks: If true, callstacks across async calls (like setTimeout, fetch, resolved Promises, etc) will be shown.
• breakOnLoad: Experimental. If true, the debug adapter will attempt to set breakpoints in scripts before they are loaded, so it can hit breakpoints at the beginnings of those scripts. Has a perf impact.
• breakOnLoadStrategy: The strategy used for breakOnLoad. Options are 'Instrument' or 'Regex'. Instrument '[tells] Chrome to pause as each script is loaded, resolving sourcemaps and setting breakpoints' Regex '[s]ets breakpoints optimistically in files with the same name as the file in which the breakpoint is set.'

Skip files / Blackboxing / Ignore files

You can use the skipFiles property to ignore/blackbox specific files while debugging. For example, if you set 'skipFiles': ['jquery.js'], then you will skip any file named 'jquery.js' when stepping through your code. You also won't break on exceptions thrown from 'jquery.js'. This works the same as 'blackboxing scripts' in Chrome DevTools.

The supported formats are:

• The name of a file (like jquery.js)
• The name of a folder, under which to skip all scripts (like node_modules)
• A path glob, to skip all scripts that match (like node_modules/react/*.min.js)

Page refreshing

This debugger also enables you to refresh your target by simply hitting the restart button in the debugger UI. Additionally you can map the refresh action to your favorite keyboard shortcut by adding the following key mapping to Key Bindings:

Read more here https://github.com/Microsoft/vscode-chrome-debug-core/issues/91#issuecomment-265027348

Sourcemaps

The debugger uses sourcemaps to let you debug with your original sources, but sometimes the sourcemaps aren't generated properly and overrides are needed. In the config we support sourceMapPathOverrides, a mapping of source paths from the sourcemap, to the locations of these sources on disk. Useful when the sourcemap isn't accurate or can't be fixed in the build process.

Google Chrome Settings

The left hand side of the mapping is a pattern that can contain a wildcard, and will be tested against the sourceRoot + sources entry in the source map. If it matches, the source file will be resolved to the path on the right hand side, which should be an absolute path to the source file on disk.

A few mappings are applied by default, corresponding to some common default configs for Webpack and Meteor:

If you set sourceMapPathOverrides in your launch config, that will override these defaults. ${workspaceFolder} and ${webRoot} can be used here. If you aren't sure what the left side should be, you can use the .scripts command (details below). You can also use the trace option to see the contents of the sourcemap, or look at the paths of the sources in Chrome DevTools, or open your .js.map file and check the values manually.

Ionic/gulp-sourcemaps note

Ionic and gulp-sourcemaps output a sourceRoot of '/source/' by default. If you can't fix this via your build config, I suggest this setting:

Usage with remote VS Code extensions

This extension can be used with the VS Code Remote Extensions to debug an app in a local Chrome window. Here's an example workflow using the Remote - SSH extension:

• Connect to the SSH remote where your project is located
• Launch the development server on the remote
• Run the 'Forward Port From Active Host' command to forward the port the server is listening on. For example, if your development server is listening on port 3000, forward port 3000 to the local machine.
• Start your 'chrome' launch config
• Chrome should start on the local machine, accessing your app via the forwarded port
• Debugging works as normally

There are a couple caveats to this workflow:

• Since the extension can't currently access the remote disk, sourcemaps can't be read from disk. If sourcemaps are inlined, they will still be used. If possible, they will be downloaded through your webserver.
• In a local window, when resolving your script locations with webRoot/pathMapping, the extension does some searching for the correct script. Again, since the extension can't check the remote disk, the extension can't do this searching, so your webRoot/pathMapping must be exactly accurate to resolve the script location.

If you have any other issues, please open an issue.

Troubleshooting

My breakpoints aren't hit. What's wrong?

If your breakpoints aren't hit, it's most likely a sourcemapping issue or because you are having breakpoints in immediately executed code. If you for example have a breakpoint in a render function that runs on page load, sometimes our debugger might not be attached to Chrome before the code has been executed. This means that you will have to refresh the page in Chrome after we have attached from VS Code to hit your breakpoint.

Alternatively, we have an experimental 'break-on-load' configuration option which will make this timing issue more transparent. It landed in https://github.com/microsoft/vscode-chrome-debug-core/pull/241.

If you have a sourcemapping issue, please see https://github.com/Microsoft/vscode-chrome-debug#sourcemaps

Cannot connect to the target: connect ECONNREFUSED 127.0.0.1:9222

This message means that the extension can't attach to Chrome, because Chrome wasn't launched in debug mode. Here are some things to try:

• If using an attach type config, ensure that you launched Chrome using --remote-debugging-port=9222. And if there was already a running instance, close it first or see note about --user-data-dir above.
• Ensure that the port property matches the port on which Chrome is listening for remote debugging connections. This is 9222 by default. Ensure nothing else is using this port, including your web server. If something else on your computer responds at http://localhost:9222, then set a different port.
• If using a launch type config with the userDataDir option explicitly disabled, close other running instances of Chrome - if Chrome is already running, the extension may not be able to attach, when using launch mode. Chrome can even stay running in the background when all its windows are closed, which will interfere - check the taskbar or kill the process if necessary.
• If all else fails, try to navigate to http://localhost:<port>/json in a browser when you see this message - if there is no response, then something is wrong upstream of the extension. If there is a page of JSON returned, then ensure that the port in the launch config matches the port in that url.

General things to try if you're having issues:

• Ensure webRoot is set correctly if needed
• Look at your sourcemap config carefully. A sourcemap has a path to the source files, and this extension uses that path to find the original source files on disk. Check the sourceRoot and sources properties in your sourcemap and make sure that they can be combined with the webRoot property in your launch config to build the correct path to the original source files.
• This extension ignores sources that are inlined in the sourcemap - you may have a setup that works in Chrome Dev Tools, but not this extension, because the paths are incorrect, but Chrome Dev Tools are reading the inlined source content.
• Check the console for warnings that this extension prints in some cases when it can't attach.
• Ensure the code in Chrome matches the code in Code. Chrome may cache an old version.
• If your breakpoints bind, but aren't hit, try refreshing the page. If you set a breakpoint in code that runs immediately when the page loads, you won't hit that breakpoint until you refresh the page.
• File a bug in this extension's GitHub repo, including the debug adapter log file. Create the log file by setting the 'trace' field in your launch config and reproducing the issue. It will print the path to the log file at the top of the Debug Console. You can drag this file into an issue comment to upload it to GitHub.
• If you're using Webpack, we recommend using the 'devtool': 'source-map' option (in your webpack.config.js file) as the others produce lower-fidelity sourcemaps and you may have issues setting breakpoints. See the full list of devtool options for webpack for more information.

Chrome Configuration Profile Mac

The .scripts command

This feature is extremely useful for understanding how the extension maps files in your workspace to files running in Chrome. You can enter .scripts in the Debug Console to see a listing of all scripts loaded in the runtime, their sourcemap information, and how they are mapped to files on disk. The format is like this:

Example:

Chrome Config Settings

If the paths of your source files show as not being resolved correctly here, you may have to change sourceMapPathOverrides or webRoot to help the debugger resolve them to real paths on disk.

If you are wondering what a script is, for example, that 'eval' script, you can also use .scripts to get its contents: .scripts eval://43.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.