3. System Requirements
Prerequisites for managing Windows Devices via Google Workspace
AN ADMIN GUIDE TO MANAGE
WINDOWS DEVICES VIA GOOGLE
- Google recently launched an option for Google Workspace (and Cloud Identity) customers to manage Windows 10 devices right from Google Admin Console.
- I invested sometime in learning how it works, so I can help community manage Windows devices via Google Workspace and get more out of their investment in Google.
- Let me share everything I learnt, and hopefully it would help you seamlessly manage your Windows 10 devices as a Google Workspace or Cloud Identity Administrator.
Table of Contents
3. System Requirements
Prerequisites for managing Windows Devices via Google Workspace
Chapter # 1
Google Workspace Windows Management Overview
Google Workspace Windows Management Overview
I certainly agree that each prominent operating system in the market today (e.g Windows, Mac, ChromeOS, or Linux) can get the job done, and it essentially is a matter of personal preference based on what works best for you.
I switched from Windows to Mac back in 2013 and never looked back, however some of my friends & colleagues love the Windows operating system and I respect their choice.
Instead of imposing, smart organizations prefer to provide their users with a choice and let them decide what make them more productive, this might be the reason vendors like Google & Microsoft are also investing in interoperability along with building their ecosystem.
As an example, Microsoft allows organizations to manage their android devices via intune, and Google also provides an option to manage devices from other vendors.
Microsoft of course provides a way to manage Windows devices, but won’t it be better if Google provides that option to Google Workspace customers and let you get more out of your investment in Google (especially if you either do not use Active Directory or have plans to replace it with Google Directory)?
Drum roll…….It is time for some good news:)
Google indeed recently launched an option where Google Workspace customers like you would be able to manage Windows 10 devices right from Google Workspace or Google Cloud Identity Admin Console.
This new Windows device management functionality works seamlessly with your Active Directory too, and just in case if you are fortunate to get rid of Active Directory, then even better, you can still manage your Windows devices from the Google admin console.
In this blog post, we will cover things in great detail and hopefully it should help you understand how windows devices management via Google works, and how you can set it up in your environment.
Let us first start with understanding what exactly I mean when i say “Manage Windows devices via Google Workspace”
Well, essentially 3 things
1. Authenticate to Windows via Google Workspace : It offers an authentication method where your users should be able to login to Windows 10 devices via their Google Workspace or Google Cloud Identity credentials.
2. Windows devices Inventory : It offers an easy to manage inventory management system where all your connected Windows devices can be seen in your Google Workspace Admin console along with some metadata like last sync time, OS version, and an option to block, delete or wipe these devices.
3. Windows devices management : It allows to manage Windows settings on enrolled devices, you may think of it like pushing your GPO policies right from your Google Workspace or Google Cloud Identity admin console (e.g enable camera, disable USB etc).
Manage Windows 10 devices via Google – Terminology :
Google calls this “Enhanced Desktop Security for Windows”, which has two modules-:
- Google Credential Provider for Windows (GCPW) : It is an installable utility that you install on users windows devices (either manually or via app distribution) to let them sign in on Windows via their Google account. It is available to all Google Workspace and Cloud Identity plans.
- Windows Device Management : It allows pushing policies to Windows 10 devices (e.g manage windows updates, enable camera, disable USB etc) which is only available in selective Google Workspace and Google Cloud Identity plans (more details about it are provided in system requirements section).
Benefits of managing your Windows devices via Google Workspace or Google Cloud Identity :
Security : You should be able to push security policies (e.g disable camera, usb etc) along with option to sign users out or wipe data from their Windows devices.
As your users would be able to login to windows 10 devices via their Google credentials, you can also enforce multi factor authentication (MFA) for secure login.
Rich user experience : Once your users sign in to windows devices via their Google credentials, a session is established, which helps them to login to any Google Workspace (e.g Gmail, Drive) or assigned SAML application (e.g Salesforce) without a need to enter credentials again.
Your users will not need to remember different sets of credentials (e.g for Windows, for Google Workspace, for 3rd party applications), just login to Windows via Google Workspace or Google Cloud Identity once, then login to any assigned applications via Single Sign on (SSO).
Updates management : You should be able to control how and when your users get Microsoft windows device security updates.
Increased ROI : Till the time you have supported Google Workspace or Google Cloud Identity subscription, you do not need any additional license specifically for managing your windows devices via Google.
Now, with this context, let us understand how Google Workspace provides your Windows users rich login experience and let you seamlessly manage their windows devices.
Chapter # 2
How does Windows Management work?
Windows Authentication & Management via Google Workspace
I have put some flowcharts below which would help you understand it better, but here is the summarized version of how managing Windows devices via Google works.
Google offers a utility called Google Credential Provider for Windows (GCPW) which you install on your users Windows devices either manually or via your preferred application distribution tool (PowerShell script is included later in this post).
This utility (along with a few registry changes) does a few things-:
- At the time of GCPW installation on Windows devices, you tell Google to either associate Google account with your existing Windows profile (e.g local or AD profile) or create a new Windows profile.
- After GCPW installation on Windows devices, users sign in with their Google Workspace account password, GCPW then either create and login to a new Windows profile or to an existing one based on your configuration.
- Though Internet connection is required for the first login via Google to sync Google password to Windows (and to push custom settings if you have those in place), but subsequent logins should work fine even without internet access (unless Google session expired or password is changed) because now essentially their Windows password is same as Google Workspace.
Password Synchronization :
This also requires us to keep our Google Workspace and Windows password in sync. There are couple of options available for you to keep these passwords in sync, lets explore them-:
- If your windows user changes his/her Google Workspace password, then this new password should be synchronized with Windows at next login via Google Workspace (however user should be connected to internet for this).
if the user logs in offline mode after changing his/her Google Workspace password, then old password should be entered to login to Windows as GCPW didn’t get a chance to push updated password (due to being offline). - If your user changes password on Windows for the Windows local profile, then GCPW would detect and push this changed password securely to Google Workspace.
- However, if your user has an Active directory managed Windows profile, and change the password, then user would either need to change the Google Workspace password manually (make it same as Windows).
You may consider utilizing Google Workspace Password Sync (GSPS) utility offered by Google, which detects AD password changes and automatically push them to Google Workspace (via Directory API) to keep them in sync.
Note : Your Google Workspace or Cloud Identity password policy should be same (or stronger) than Active Directory or Windows password requirements.
Windows User
Login Experience
Login to Windows via Google Workspace - User Experience
Before we start required setup to let your users login to their Windows devices via Google Workspace, let us explore user experience-:
- Non-Domain joined machines -: Users would either click on existing Windows tile, or “Add Work Account”
- Domain joined machines : Users would either click on their existing windows tile OR Other Accounts on their Windows devices.
- Above is configurable as we’ll see later in the post based on whether you want Google to create new windows profile or associate with local or AD profile.
- Your users would then be shown an option to sign in via Google where they’ll enter user email, password (and second authentication factor if you have enforced it).
- Based on your (configurable) profile strategy Google Credential Provider for Windows (GCPW) would either create new Windows profile or associate it with existing local or AD windows profile.
Note -: After successful authentication, GCPW looks for a custom attribute and its value (e.g SamAccountName for AD, and un:Windows username for local windows profile) in Google Workspace directory, if found, it then checks if a Windows profile exists for this user and finally associates Google Workspace account with this profile, otherwise it creates a new windows profile for Google Workspace user.
- Once the user logins to Windows (either new or existing profile), this device will be enrolled in GCPW, and you should be able to see it (along with metadata) under device inventory in Google Workspace admin console.
- If you have supported Google Workspace or Google Cloud Identity subscription and you have not disabled auto enrollment via registry changes (cover later in this post) , then these devices would be automatically enrolled in Enhanced Desktop Security, so you can push policies to them.
Login to Windows via Google Workspace - Behind the scenes
Chapter # 3
Windows Devices Management Prerequisites
System Requirements for managing Windows 10 devices via Google Workspace (or Google Cloud Identity)
1. Supported Google Workspace or Google Cloud Identity Subscription
GCPW (which includes login via Google, SSO to Google and SAML Apps, and windows devices inventory) is available to all Google Workspace & Cloud Identity subscriptions, however Windows management (e.g pushing custom settings / policies) is included in specific plans, following table should be helpful to understand it.
| Google Workspace or Cloud Identity plan | GCPW | Windows Management |
|---|---|---|
| Google Workspace Basic | Available | Not Available |
| Google Workspace Business | Available | Not Available |
| Google Workspace Enterprise | Available | Available |
| Google Cloud Identity Free | Available | Not Available |
| Google Cloud Identity Premium | Available | Available |
| Google Workspace Essentials | Available | Not Available |
| Google Workspace Enterprise Essentials | Available | Available |
| Google Workspace Education | Available | Not Available |
| Google Workspace Education Enterprise | Available | Available |
Note : For Windows management (e.g pushing policies to user devices), each user should have a supported Google Workspace or Google Cloud license.
2. Supported Windows 10 Version
— You would need version 1803 or newer for Windows 10 Pro, Pro for Workstations, Enterprise, or Education.
3. Supported Google Chrome (for GCPW)
— You would need Chrome Browser 81 or later.
4. Local Administration Rights & enough storage
— Local system admin rights to install Google Credential Provider for Windows (GCPW) on Windows devices if you are doing manual install on user devices (You can also deploy the installer via your app distribution tool).
— Google also recommends 100 MB available disk space for Google Chrome and 3 MB for GCPW.
Here is the reference PowerShell script provided by Google which downloads GCPW and configures the required registry to restrict sign in to Windows devices from provided domains only, simple hover on the script and it’ll give an option to copy it.
<# This script downloads Google Credential Provider for Windows from
https://tools.google.com/dlpage/gcpw/, then installs and configures it.
Windows administrator access is required to use the script. #>
<# Set the following key to the domains you want to allow users to sign in from.
For example:
$domainsAllowedToLogin = "acme1.com,acme2.com"
#>
$domainsAllowedToLogin = ""
Add-Type -AssemblyName System.Drawing
Add-Type -AssemblyName PresentationFramework
<# Check if one or more domains are set #>
if ($domainsAllowedToLogin.Equals('')) {
$msgResult = [System.Windows.MessageBox]::Show('The list of domains cannot be empty! Please edit this script.', 'GCPW', 'OK', 'Error')
exit 5
}
function Is-Admin() {
$admin = [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).groups -match 'S-1-5-32-544')
return $admin
}
<# Check if the current user is an admin and exit if they aren't. #>
if (-not (Is-Admin)) {
$result = [System.Windows.MessageBox]::Show('Please run as administrator!', 'GCPW', 'OK', 'Error')
exit 5
}
<# Choose the GCPW file to download. 32-bit and 64-bit versions have different names #>
$gcpwFileName = 'gcpwstandaloneenterprise.msi'
if ([Environment]::Is64BitOperatingSystem) {
$gcpwFileName = 'gcpwstandaloneenterprise64.msi'
}
<# Download the GCPW installer. #>
$gcpwUrlPrefix = 'https://dl.google.com/credentialprovider/'
$gcpwUri = $gcpwUrlPrefix + $gcpwFileName
Write-Host 'Downloading GCPW from' $gcpwUri
Invoke-WebRequest -Uri $gcpwUri -OutFile $gcpwFileName
<# Run the GCPW installer and wait for the installation to finish #>
$arguments = "/i `"$gcpwFileName`""
$installProcess = (Start-Process msiexec.exe -ArgumentList $arguments -PassThru -Wait)
<# Check if installation was successful #>
if ($installProcess.ExitCode -ne 0) {
$result = [System.Windows.MessageBox]::Show('Installation failed!', 'GCPW', 'OK', 'Error')
exit $installProcess.ExitCode
}
else {
$result = [System.Windows.MessageBox]::Show('Installation completed successfully!', 'GCPW', 'OK', 'Info')
}
<# Set the required registry key with the allowed domains #>
$registryPath = 'HKEY_LOCAL_MACHINE\Software\Google\GCPW'
$name = 'domains_allowed_to_login'
[microsoft.win32.registry]::SetValue($registryPath, $name, $domainsAllowedToLogin)
$domains = Get-ItemPropertyValue HKLM:\Software\Google\GCPW -Name $name
if ($domains -eq $domainsAllowedToLogin) {
$msgResult = [System.Windows.MessageBox]::Show('Configuration completed successfully!', 'GCPW', 'OK', 'Info')
}
else {
$msgResult = [System.Windows.MessageBox]::Show('Could not write to registry. Configuration was not completed.', 'GCPW', 'OK', 'Error')
}
Chapter # 4
Windows Management via Google Workspace Setup
Manage Windows devices via Google Workspace (Admin Workflow)
Step 1
Enable Device Management
Let us first enable device management in Google Workspace Admin console so our users can be enrolled at first login and our policies can be pushed.
Enable Enhanced Desktop Security & apply policies
Let us start with enabling enhanced desktop security and applying a few policies to our Windows devices.
Note -: If you do not meet requirements for “Enhanced Desktop Security” as mentioned above, OR if you only want to setup Google Credential Provider for Windows (authentication) so your users can login via Google Workspace, then you can skip this step and go to Step 2 of the setup.
In my case, I use Google Workspace Enterprise, and prefer to automatically enroll my windows devices to enhanced desktop security, and also apply a few policies on my users first Windows login via Google Workspace.
So, I will login to Google Workspace Admin Console, and go to Devices as shown below.
If you have supported Google Workspace or Google Cloud Identity subscription, you would see “Windows Settings” under Settings section as shown in below screenshot. Click on “Windows Settings” in this section.
Here you can enable “Enhanced Desktop Security” or device management on either the root organization (which means all users) or selective child organization units (which means it’ll apply only to the users who belong to these child org units).
Click on save changes.
Step 2
Push Custom Settings
If you have supported Google Workspace plan, you can also push custom settings either now, or you can do it later too. I will push couple of custom settings now for the demonstration.
Apply custom settings for Windows 10 devices
This is only available in Enhanced Desktop Security, you may refer to system requirements above to see which Google Workspace and Cloud Identity plans offer it.
As per Microsoft “Windows 10 custom profiles use Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings to configure different features. These settings are typically used by mobile device manufacturers to control features on the device”.
Google provides you option to apply custom settings to your Windows 10 devices via OMA-URI where essentially you put the URI for a specific policy (e.g Allow Camera) and then enter its value (e.g 0 to disable camera, 1 to enable camera).
Let us create a simple policy of restricting our Windows users to use camera on device.
In your Google Workspace or Google Cloud Identity Admin Console, go to device management, click on Windows settings (as shown in the screenshot above) and then click on custom settings.
You would see your existing custom policies here, I do not have one yet, so i’ll click on “Add a custom setting” to create one.
Though you can find a list of OMA-URIs on Microsoft’s site, but Google also let you easily search while creating them in Google Workspace Admin console.
I will search for “Camera” to see associated custom policies option, and then select the one which allows or block camera usage (as shown in the screenshot below).
Your OMA-URI based custom setting policy would look like this, once configured click on Next.
Here you have the flexibility to define the scope for this custom policy, you can either apply it to all users by selecting your root organizational unit OR you can go granular by selecting child organizational units so it only applies to users who belong to child org units.
Now, ideally, when my Windows user login via Google Workspace credentials, camera will not be available to use, and user will not be able to enable it.
Additional Steps - Depending on your profile strategy.
I want Google to create a new Windows profile when my users login to Windows via their Google Workspace or Google Cloud Identity credentials, however if you want, you can also associate their existing Windows local or Active directory profile with Google account.
You should follow either of the following steps only if want to associate users’ Google account with local or AD windows profile, otherwise skip them.
Expand Additional Step (if required) You can click on the + icon below to expand additional step (if required).
In this post, I will be configure Google to create a new windows profile with my users Google credentials, however if you want to rather associate your users Google profile with existing Windows Active Directory Profile, then you should perform this additional setup.
1. Login to your Google Admin console –> go to Users –> click on Manage Custom Attributes
2. Create a custom attribute which will be looked up by GCPW for associating Google account with existing Windows AD profile.
(i) Category name should be “Enhanced desktop security“.
(ii) Custom field name should exactly be “AD accounts“.
(iii) Info type should be “Text“.
(iv) Visibility should be “Visible to User and Admin“.
(v) No. of values should be “Multi-value“.
(vi) Save changes
3. Populate the newly created custom attribute with the AD user sAMAccountName in format: domain\username.
For e.g my AD domain name is ad.goldyarora.com and my sAMAccountName is admin, so I would enter ad.goldyarora.com\admin as shown in the screenshot below.
In this post, I will configure Google to create a new windows profile with my users Google credentials, however if you want to rather associate your users Google profile with existing Windows local profile, then you should perform this additional setup.
1. Login to your Google Admin console –> go to Users –> click on Manage Custom Attributes
2. Create a custom attribute which will be looked up by GCPW for associating Google account with existing Windows local profile.
(i) Category name should be “Enhanced desktop security“.
(ii) Custom field name should exactly be “Local Windows accounts“.
(iii) Info type should be “Text“.
(iv) Visibility should be “Visible to User and Admin“.
(v) No. of values should be “Multi-value“.
(vi) Save changes
3. Populate this newly created custom attribute with local Windows user’s user name in the format un:username.
For e.g, my local windows profile name is admin, so i would enter un:admin as shown in the screenshot below.
3.1 If you want to restrict only one user to this respective device, then you should also write the device serial number along with the user name separated by comma (e.g un:admin, sn:123456) as shown in the screenshot below.
Step 3
Download & Install GCPW
We now need to download and install Google Credential Provider for Windows (GCPW). Please ensure you have system requirements in place as mentioned in above section.
Google Credential Provider for Windows Installation
You can either search Google for “Google Credential Provider for Windows” or click on this link https://tools.google.com/dlpage/gcpw
Download the version compatible with your system, and then run it with the local admin rights.
Allow the system to run the installation as shown in the screenshot below.
GCPW installation should start now and may take just a minute to finish.
Once the installation is finished, you should-:
(1) Go the path shown in the screenshot below
(2) Ensure that it has created 3 files as shown below.
Step 4
Make Registry Changes
GCPS includes some required and optional registry changes, let us understand and configure them in this section.
Available Registry Settings
Registry Setting
Domains Allowed to Login Description : This setting restricts users to login to Windows devices only if their email belongs to any of these domains. Any user whom email does not belong to these domains will get an error when login to Windows via Google Workspace. By default, no domains are allowed to sign in with GCPW. Setting Type : Required
| Configuration
Configuration Instructions
If required, Please look at the screenshot based instructions later in this post where I perform this registry change. |
Disable Device Enrollment By default device enrollment is enabled, however if you want to use GCPW for authentication only, you may consider disabling device enrollment either here or in Google Workspace Admin Console. Setting Type : Optional
|
Configuration Instructions
|
Session Validity Default behavior : No value, online sign-in is not enforced. |
Configuration Instructions
|
Default behavior : Multiple users are allowed to sign in to Windows device via their Google Workspace account. |
Configuration Instructions
|
Windows Profile Association This setting helps you define whether you want Google to create new Windows profile (default), or rather associate Windows local or AD profile with Google account. Default behavior : Google does not associate existing Windows profile, and let users click on “Add Work Account” to create a new Windows profile via Google Workspace. |
Configuration Instructions
|
Make Registry Changes
Though you may configure the optional registry changes as well if required, however I would configure only the required one for this demonstration.
Go to your Windows search and type regedit as shown below.
1. Go to HKEY_LOCAL_MACHINE
2. Go to GCPW.
3. Right click and click on New.
4. Click on “String Value” and name it domains_allowed_to_login
Now, right click on domains_allowed_to_login and enter the comma separated Google Workspace or Google Cloud Identity domain names which you want to allow for login in to this Windows device.
I want my users to login from any of my three Google Workspace domains, so i have entered them separated by comma, however if you have only domain, simply enter it here.
Your completed domains_allowed_to_login entry should look like the screenshot below.
Additional Steps - Depending on your profile strategy.
If you decided to rather associate your existing Windows local or Active directory profile with Google account, then you would need to make an additional registry setting, which will let GCPW look for your custom attribute that you created in Google directory.
You should follow either of the following step only if want to associate users Google account with local or AD windows profile.
Expand Additional Step (if required) You can click on the + icon below to expand additional step (if required).
If you want to associate users’ existing Windows profile with their Google Workspace or Google Cloud Identity account, then create this registry key as follows :
Before we create the registry key, we’ll need user’s security identifier (e.g SID), you can use following command in CMD on the respective device to find user’s SID.
Commands :
If you don’t know the user name : wmic useraccount get name, sid
If you know the user name : wmic useraccount where name = “Your User Name” get sid
Go to registry settings (regedit) –> HKEY_LOCAL_MACHINE –> Software –> right click on GCPW and create a new Key called “Users”
Now, right click on the newly created Users folder to create a new key with the SID you got above.
You should now right click on the SID folder, and create a new String Value called “email” as shown in the screenshot below.
You should now right click to modify the email value.
Enter your Google Workspace or Google Cloud Identity user’s full email address here as shown below.
Your entry would look like the screenshot below.
Step 5
Configuration Testing
As we are now done with our setup, let us go ahead and perform testing to ensure everything works as we expected
Now sign out from your Windows device, and let’s start testing login to it via any of the Google Workspace domains we allowed above.
You would notice a new “Add Work Account” option with Google logo as shown in the screenshot below, click on it.
Note : If your admin has setup to associate existing Windows profile with Google account, then you should be able to rather click on your existing Windows profile to login via Google.
After you click on Add Work Account, you would see a Google screen suggesting you to sign in with your work account as you see below. Click on the arrow to start login via Google process.
Enter your Google Workspace or Google Cloud Identity email address.
Enter your Google Workspace or Google Cloud Identity account’s password.
As this is our first login, Google would inform us that our Google Workspace admin can monitor and mange this device. Click on “I agree” to continue with the process.
Your new windows profile is now getting ready, it may take a few minutes.
Note -: If you associated your existing local or AD windows profile with Google Workspace, then new profile would not be created, and you would rather straight away login to your Windows.
Your new Windows profile has been created via Google Workspace, and is now ready for you.
However, you would notice that user can neither use camera, nor change its setting due to the custom setting we pushed earlier.
Sign in to Google Workspace & assigned SAML Applications
When you login to Windows via your Google Workspace or Google Cloud Identity credentials, a session is established which lets you login to assigned Google Workspace and SAML applications.
When you launch Google Chrome after login to Windows via Google Workspace, you would be asked to link your profile/data to your Google Workspace organization.
Now you can go to any Google Workspace application url (e.g drive.google.com, mail.google.com etc), or to your Google Workspace dashboard at gsuite.google.com/dashboard where you’ll see all the applications assigned to you.
Click on any of these application to login without a need to enter credentials again.
You should be logged into the application via an active session as shown in the screenshot below.
Device Enrollment Reporting
When your users sign in to Windows via Google Workspace, they get enroll in Google Credential Provider for Windows, GCPW (and also in Enhanced Desktop Security if you have automatic enrollment enabled along with supported Google Workspace or Cloud Identity subscription).
To view the devices inventory, go to your Google Workspace admin console (admin.google.com) and click on devices.
Now click on Endpoints as shown in the screenshot below.
Here you can either search for the Windows device by user name or other properties, or add a filter to view devices based on your criteria (e.g OS matches Windows AND status = Pending Approval).
Here you should be able to perform a few operations including-:
- Search and filter your devices based on criteria (e.g OS, user, last sync, serial no. etc).
- Look at device information like user email, last sync, OS version etc.
- Sign out the user, wipe device (factory reset), unenroll, and delete the device.
Chapter # 5 – Windows Management via Google Workspace
Troubleshooting & FAQs
FAQ
Most frequent questions and answers about managing Windows devices via Google
This error indicates you are trying to sign in with the email domain that is not included in Domains Allowed to Login registry setting.
Solution : Either try the email address on the allowed domain, or add the required domain to the registry key as shown above in the change registry settings section.
This error indicates Admin has not yet configured Domains Allowed to Login registry setting.
Solution : Add the required domain/s in the Domains Allowed to Login registry key.
This error indicates that the user’s Google and Windows passwords are not in sync, This message appears when user enters the wrong Windows password.
Solution : Sync Google and Windows password.
As per Google,
To fix this issue, you can install or reinstall the Chrome browser on the user’s device.
However, in my experience, this error also occurs when you install GCPW on a non supported Windows version (e.g Windows Server 2016).
Ask it in the comments below, and I would try to answer it (if i can) as soon as I get time.
RECOMMENDED READING
As you just read The Definitive Google Workspace Admin guide to Manage Windows Devices, I would recommend following as complimentary reading.
Google Workspace to Office 365 SSO and Provisioning Guide
Read More →
32 thoughts on “The Definitive Google Workspace Admin guide to Manage Windows Devices”
I have this issue with one computer that used to work fine with GPCW but suddently does not. Chrome is installed and working in normal 64 bit program folder. Special user is in Log In As Batch Job.
“Can’t open the Google sign-in screen because there’s an issue with the Chrome installation on this device. Contact your administrator. ”
Update: As I was typing this I went into look at my user accounts and I have a gaia AND a gaia2 user! I deleted both users and uninstalled and then reinstalled GPCW. Even without a reboot I am now able to use GPCW again. Hope this helps someone.
Is it possible to do any of the following via Custom OMA-URI (or some other means from the Google Workspace / Google Cloud Identity admin panel)?
* Create a scheduled task on all machines in a Google OU
* Enforce a registry setting on all machines in a Google OU
* Run a powershell cmd-let on all machines in a Google OU (at startup, periodically, etc)
I see that we can create an MSI file, put the MSI file on an HTTP, HTTPS, or FTP server, and then use OMA-URI to install that MSI. But it would be nice if we didn’t have to create MSI files that do nothing be modify the registry.
We don’t currently have a Windows server with Active Directory and I’d like to avoid that if possible. MS Intune at least offers management of Scheduled Tasks it looks like, but I don’t think that’s via OMA-URI.
Good stuff here Goldy! Thanks.
I’ve been trying to find some guidelines on how to synchronise the AD username to Google Console, any pointers on that? (We are already using GCDS and I have already created the “Enhanced desktop security” and “AD accounts” in the console but I haven’t find a way to sync or to edit the GCDS config)
My goal is to dis-join all PCs from Active Directory after I get the user profiles switched to GCPW. My question is, if I use the Custom Attributes to associate their domain profile to the Google authentication, what will happen to the profiles after I disjoin the computer from the domain? Thanks!
Hi Goldy,
How to enable Tamper protection for GCPW software to avoid uninstallation of this software by users.
Also how to change the device name in Devices Inventory
Thanks,
Arul
Only local admin users can uninstall. Don’t let the user be local admin.
Has anybody had any success with applying ADMX-backed policies with GWE? This is the only thing preventing us rolling out GWE across our business.
I’ve followed the guide that Google provide but the policies fail to apply. There’s probably a nuance in the OMA-URI path that I haven’t got right – so it would be good to hear from others that have had some success.
Hi Goldy, thank you for taking the time to type this informative blog/guide to the working of GCPW and Windows Device Management. I have installed GCPW and already log in with it, and have tested several policies that work great. Yet some of the policies like:
– ./Device/Vendor/MSFT/Policy/Config/System/DisableOneDriveFileSync (value 1 block access)
– ./Vendor/MSFT/Personalization/DesktopImageUrl (path to the jpg image on my Windows 10 C: folder)
Nothing happens (even after restart/shut down). Could you please elborate as to what step is required for completing the policies and getting them activated? Thank you in advance for your reply.
I am trying to match The Device ID or the Device Resource ID (Devices > Overview > Endpoints) pick a certain device and it has listed both a device ID and a resource ID. So for example, my computer that I know which one it is, how do I obtain the resource or device ID from my windows 10 computer? I have searched online for probably 30-45 minutes and have not come close to finding the answer. Thank you!
How to Remove User Accounts From the Login Screen in Windows?
You have to login as a local Administrator and remove the User through Windows OS Settings
Hi ,
had a very nice read. Good work.
Were you able to install a EXE file hosted on a public Server via Google Policy on a windows device?
Hi John,
I was able to do this by wrapping the EXE as an MSI and hosting the file on a bucket.
Then it is installed on the device using the custom settings section.
https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F10065085%3Fhl%3Den&product_context=10065085&product_name=UnuFlow&trigger_context=a
We are using GCPW, but we are also using Advanced Account Protection and using Security Keys. Not sure if anyone else is having this issue, but during login, I will receive an error that my security keys are not enrolled, and that i will have to use a different key, even though my security keys are enrolled.
I tried the block camera after installation of the GCPW, it doesn’t seem to work, even after a reboot, the logged-in user has cloud identity premium. Any idea what else we need to configure?
Windows 10 Pro is installed, version 21H1.
Thanks a lot.
when I try to log I get the following message..
this email isnt allowed to sight in, try again with an account you use for work or school.
Hi Goldy, you are an amazing Google Knowledgebase. Thanks for sharing this wonderful features. I am also a Google Admin and work for a school. I would like to know
1. how to give the admin rights to the google profile (once created) on the windows device.
2. How to buy the windows management licenses only for few users. Don’t want to buy all the email ids on the domain. Or can I buy only one or two for trial.
You can create a Organizational Unit and apply Local Administrator policy from Windows settings in GCPW. Move the user to that OU.
You will have to override the policy for the same.
Hi Goldy,
Highly appreciate your great job here.
In order to disable the camera, you used the OMA URI : ./Device/Vendor/MSFT/Policy/Config/Camera/AllowCamera
I managed to figure out that for biometrics one should use OMA URI : ./Device/Vendor/MSFT/PassportForWork/Biometrics/Use Biometrics.
1. Could you please confirm that this is correct?
2. Do you please know the custom setting one should use in order to disable the use of PIN such that users can only login using their Google Passwords?
Thank you in advance
Would the following statement be correct?
-If I configure windows settings in google admin>devices>mobile and endpoints>windows settings. Those settings will only be applied to users in the OU I set them on and only if the windows 10 computer they are signing into has GCPW installed on it.
That is correct, you can scope it based on the Google Workspace organizational units.
Thank you for the article. Very helpful. I’m trying to figure out the piece about enrolling windows 10 devices in our google domain though. We want to manage only district owned windows 10 devices, not personal ones people use. All my windows 10 devices currently show “user Owned” in the admin console. How do I change that?
You can upload the csv containing your devices serial numbers as documented here
https://support.google.com/a/answer/7129612?hl=en-GB
Hi, we have about 500 client machines running on Gcpw with the full gambit of the above. We found a ton of bugs and caveats to he above in addition to this tutorial. However, this is the best I have found so far. We use Okta as our SSO provider. This is a very well known service and we have utilized it for about a year and a half to put Mfa in front of Gsuite logins. In fact, it even works with Gcpw. That is, until Chrome version 86. Rolling back to 85 works fine. Shortly after this they updated the GCPW Faq to include that that GCPW does not support 3rd party authentication. We have been dealing with support for about 2 months on this until it reached an engineering phase. Gsuite has supported 3rd party SSO for some time and has settings in the admin console. We know GCPW uses Chrome and we are at maybe…I would say 7-8 high end professionals troubleshoot it all with the same conclusion that Chrome version 86 breaks SSO login with Gcpw. Any thoughts on that? Thank you for this page by the way awesome work.
I used to work with Okta, and I agree its a great product which made me put together a Google Workspace Okta integration guide
so i agree that it would be great if it works with 3rd party IdPs too, though i have not tested it, but I have seen on google formal documentation that GCPW does not work with 3rd party IdPs yet.
Very Nice content here!
I am deploying GCPW. I installed GCPW and made the registry changes. However, when I restart the computer, I cannot find the “Add work account” option on the homescreen (I could find this for other computers).
Do you please know what can be the problem? Is there any workaround? Thank you very much for your help.
Cyrille
I think i have seen/faced this error when i was trying to install and run GCPW on an AWS workspace instance, solution should be to ensure system requirements, especially windows version in your case.
Nice! I am deploying GCPW to some users. It works ok until the user changes the password. Even Google Password (at accounts.google.com) or local windows password (at the lock screen, change password option). We don´t have AD. Local windows account only.
What am I doing wrong? are there someplace where i can control how often the sync occurs?
Even after sync, the password remains outdated and I have to use the old password (in g suite challenge logon or windows challenge logon).
Thanks in advanced.
1. If you change your Google password, then GCPW can take care of synchronizing this to Windows, however for this to take place, you would need to login to Windows via your new Google password (when you are connected to the internet).
2. If you change password in local Windows, isn’t Google Credential Provider for Windows (GCPW) detecting and pushing it to Google Workspace or Google Cloud Identity?
1 – I´ve tried a couple of times and I find a good delay to sync take place. Some hours I would say. I´m trying again w/ other account and another device. Other weird behavior is that when user is typing the password at dialog box at windows, the time to complete is very short. User has to typing very fast or they have to start over typing the password at Windows challenge screen.
2- No. It is not. I have some screenshot and sent it to Google Support but until now I am still with this problem. After 02 days, there are no signs of google´s password change at gsuite admin audit reports (admin.google.com). We have Google Workspace Enterprise. User has a new password at windows local account and an old password at Google Directory for sure.
Again, I´ve tried sync manually, syncs occur successfully but google´s password remain the old one. I am right now trying again after a Factory Reset at windows 10 device.
Thanks a lot.
Marcos Alves
error: a user on this computer was already added using this account please sign in with different
account give solution
It means you already created an account on this device with this Google Workspace account, try a new Google Workspace new account or login to existing account.
Also, this assume that you have kept the default allow multiple logins in Google Credential Provider for Windows (GCPW).