Before we start: about this course
This course is independent. Google did not write it, does not endorse it and has not checked it. We don't copy Google's documentation. We teach you how to read it and use it at the help desk. Google changes Admin console menus, setting names and help page addresses often. Every console path in this course was checked against Google's documentation in November 2026. Treat each path as "true on that date" and check it again before you rely on it.
Here's a real example from this autumn. Old Workspace admin help links such as support.google.com/a/answer/7491144 now return a 301 Moved Permanently redirect to a new site, knowledge.workspace.google.com. If an old runbook links to the old pages, those links are already out of date. Something similar will happen to a menu name you rely on, probably within a year.
The one-page picture
When a user says "my laptop won't sync", they're describing something on the device. The cause is usually somewhere else. Almost every Workspace device problem follows the same path:
DEVICE -> ACCOUNT -> ORGANISATIONAL UNIT (OU) -> ADMIN CONSOLE SETTING
(what the (who is (where that account or (the policy that
user sees) signed in) device sits in the tree) actually decides)
A user or device belongs to exactly one OU and gets that OU's settings. If a child OU doesn't override a setting, it inherits it from its parent. Next to each setting, the console shows Inherited or Locally applied. That label is one of the most useful things you can read as support staff.
Think of it like Windows Group Policy on AD OUs, if you've used that. The idea is the same: the account's location in the tree decides which settings it gets.
The five surfaces and where each one is controlled
Keep this map handy (paths checked in November 2026):
# SURFACE WHAT THE USER SEES WHERE IT IS CONTROLLED (Admin console > Menu)
1 Chrome browser A Chrome profile signed in with a Devices > Chrome > Settings (User & browser settings tab,
work account, or a browser the opens by default)
company has enrolled Devices > Chrome > Managed browsers (enrolled browsers)
2 ChromeOS A Chromebook with "This device is Devices > Chrome > Devices (the device list)
managed by your organisation" Devices > Chrome > Settings > Device settings
3 Windows and Mac Drive for desktop: a drive letter on Apps > Google Workspace > Drive and Docs >
(Drive for desktop) Windows, a location in Finder on Mac Google Drive for desktop
Windows device policy Sign-in through GCPW, policies Devices > Mobile & endpoints > Settings > Windows
4 iOS Gmail/Drive apps with a work account, Devices > Mobile & endpoints > Devices (device list)
5 Android a work profile with a briefcase badge Devices > Mobile & endpoints > Settings > Universal
on its apps (General > Mobile management)
A few notes on that map:
- The Chrome browser has two layers. A user signs in to a Chrome profile and brings their account's policies with them. A browser can be enrolled by the company and gets policies whoever uses it. If the two disagree, Google's documentation says enrolled browser policies take precedence over user policies. Many "I set it but it isn't applying" tickets come down to that rule.
- Drive for desktop is controlled from Apps, not Devices. It's a Drive setting, so look under Drive and Docs. On that page you'll find settings such as Allow Google Drive for desktop in your organization and Only allow Google Drive for desktop on authorized devices.
- Mac: Google's endpoint management overview covers Android, iOS, Windows and ChromeOS. It doesn't present macOS as a managed-device platform. For a Mac user, you'll mostly be supporting Chrome and Drive for desktop.
- Mobile has levels. Google's documentation describes basic management (on by default), advanced management and unmanaged. Basic gives you passcode rules, Android app management and device details. Advanced adds things like stronger password rules, remote device wipe, iOS app management and Android work profiles. This course calls the levels "fundamental" and "advanced". You'll meet the same idea under slightly different names on different console pages.
Worked example: tracing a ticket along the path
Ticket: "Priya (Finance) says the Drive for desktop app opens and then tells her it isn't allowed. It works for Tom in Sales."
Work along the path. Only look at things at this stage. Don't change anything.
1. DEVICE Priya's Windows 11 laptop. Message seen: app says it is not allowed.
2. ACCOUNT priya@example.co.uk (Admin console > Directory > Users > Priya)
-> note her OU, shown on her user page: /Staff/Finance
3. OU Tom is in /Staff/Sales. Different OU = possibly different policy.
4. SETTING Apps > Google Workspace > Drive and Docs > Google Drive for desktop
-> select /Staff/Finance in the OU pane on the left
-> "Only allow Google Drive for desktop on authorized devices": ON
-> label reads "Locally applied" (someone set it on Finance itself)
-> select /Staff/Sales: setting OFF, label "Inherited"
What this tells you: nothing is broken. A policy someone chose on purpose is doing its job. Priya's laptop probably isn't an authorised company device. Your job is to explain this to Priya and escalate to the policy owner if she needs access. Switching the setting off isn't your call.
Gotcha: changes take time. Google's Windows settings documentation, for example, says a change can take 3 to 6 hours to reach devices. Something that "didn't work" five minutes ago may just not have arrived yet.
Why we date everything
Three habits run through this whole course:
- Write the date on your notes. For example: "Path checked 2026-11-02." If a colleague finds the menu has moved, they know your note is out of date, not wrong.
- Look before you change. Open the setting, read the OU and read the Inherited or Locally applied label before you change anything.
- Say when something is unconfirmed. If you can't find a limit or setting in Google's current documentation, say so in the ticket. Don't guess.
Key takeaways
- Every device problem follows the path device -> account -> OU -> Admin console setting. An account or device sits in exactly one OU and inherits from its parents unless that OU overrides the setting.
- Chrome: Devices > Chrome. Mobile and Windows: Devices > Mobile & endpoints. Drive for desktop: Apps > Google Workspace > Drive and Docs.
- For enrolled Chrome browsers, browser policy takes precedence over user policy.
- Inherited vs Locally applied tells you where a setting was decided.
- This course is independent of Google and doesn't copy its documentation. Every path here was checked in November 2026, so check it again and date your own notes.