Chromebook Client Pre-Requisites

Start with one known test Chromebook. Your goal is to find its Google-enrolled record in FileWave, then read the inventory available for that device. Google Admin Console owns ChromeOS enrollment and policy. FileWave synchronizes Google's device records; the optional FileWave Inventory Extension adds direct device inventory and communication. These are separate checkpoints, not a desktop Client installation.

Before setup, email the total number of Provisioned Chromebooks in Google Admin Console to your FileWave Account Executive or Systems Engineer (SE). Request the temporary FileWave activation code and confirm capacity under Server → Activation Code in Central. Chromebook Management says FileWave synchronizes the full Chromebook device list, and insufficient Chromebook licenses can prevent a Model Update. Do not test that limit by committing a model.

Your exercise focuses on one test device, but the connector can synchronize the full Chromebook list. A selected OU can scope a Google policy; it does not establish a one-OU FileWave synchronization or licensing boundary. Have the Google administrator and SE approve the actual organization-wide import and license requirement before configuring or synchronizing a new integration. If that scope is unsuitable, stop and ask them for an approved evaluation environment.

Google enrollment licensing is separate from FileWave activation. Have your Google administrator confirm the applicable ChromeOS Enterprise Upgrade or ChromeOS Education Upgrade, availability in your region, accepted terms, and enrollment permissions for the test user. The ordinary signed-in-user route here is not the Kiosk & Signage route. Consult Google's enrollment requirements. The older Google education products and partner search links are purchasing contacts, not a reliable country-support test; absence from a sales-form dropdown does not determine eligibility.

Chromebook features: choose what you need

---

• Google-synchronized inventory and OU information: the first outcome. Google device and group records are not ordinary FileWave Client groups that you can delete independently.
• Additional hardware and software/extension inventory and user activity: the optional Inventory Extension adds installed apps/extensions, current user, network, fonts, and storage information. Check available fields rather than expecting every field on every device.
• FileWave and Google Custom Fields: a later exercise. ChromeOS annotated fields can write back to Google immediately when saved; they are not passive inventory labels.
• Location Tracking: optional, with explicit privacy approval and effective geolocation policy.
• Google OU creation, renaming and moving devices; disable/deprovision; Powerwash & Wipe Users; reboot: management actions, not checks for this exercise. OU changes can change inherited policy, and wipes can destroy data.

For capability and timing details, see Inventory Extension Capabilities and Inventory Extension Behavior. Neither an imported record nor a successful sync proves that the extension is installed or that an action completed.

Setup

Required items and owner checks

• An organization-controlled Google domain and Google Cloud/Firebase project, with its administrators available. Do not use a personal account or replace an existing integration to make room for this test.
• One approved Chromebook, with its serial number recorded. If already enterprise-enrolled in the correct Google organization, leave it enrolled. Otherwise follow Chromebook Enrollment after the connector is ready.
• An authorized enrollment user and an agreed Google OU structure. Review the effective policies for both the user and device, including inherited settings. A new test OU is not automatically isolated.
• A running, supported FileWave Server and matching Central, enough FileWave Chromebook licenses for the full synchronized scope, and a root-trusted SSL certificate, not a self-signed certificate.
• Required network access confirmed with the server/network owner. Use Default TCP and UDP Port Usage for the relevant ChromeOS traffic, not as an instruction to open every listed port.
• Google administrator approval for API access, IAM permissions, service-account key handling and domain-wide delegation. Google requires a super administrator to authorize domain-wide delegation; that does not establish the minimum role the FileWave delegated user needs during normal operation.

If the intended connector is already working, verify its project/account, license scope and sync status, then continue to enrollment. Do not create another service account or rotate credentials just to repeat this guide. For new setup, the Google owner and SE must first agree the release-appropriate permission configuration. The setup details below include older instructions for review; they do not authorize broad role grants.

Hosted users do not run server shell commands or restart services. Ask your SE to coordinate hosted certificate, connectivity or service work. For self-managed servers, those tasks belong to the authorized server owner under an approved procedure.

Google Cloud Messaging / Firebase setup — ChromeOS only

Firebase Cloud Messaging provides the push-notification channel for the Chromebook integration. Android Enterprise does not require this separate ChromeOS Google Cloud Messaging/Firebase configuration. If Android is your goal, use Configure Android Enterprise in FileWave instead. Its activation JSON is not the ChromeOS service-account key or extension policy.

For a new, owner-approved ChromeOS project:

1. Open Firebase Console and sign in with the organization-controlled account approved for this setup.
2. Accept applicable agreements only with organizational authority.
3. Select Get started with a Firebase project, or the equivalent project-creation control in the current console.

Existing Firebase project-start example; console wording may differ.

Enter a recognizable project name and confirm the intended organization before continuing. The organization shown in the example is illustrative, not a value to copy. Some account types do not offer an organization selector. Stop if the expected organization is missing.

The documented FileWave setup disables Google Analytics for this project; Analytics is not part of this exercise. Follow the current console's create/continue prompts without enabling unrelated optional products.

Once the project is created, select Continue and record its identity for the owner. Use this same project for the FileWave integration's service account and required Firebase APIs.

---

Configure Google-to-FileWave synchronization

This connects FileWave to Google inventory. It does not enroll a Chromebook, install the Inventory Extension, or enable location tracking by itself. Complete it only after the import scope, licensing and security configuration have been approved.

Enable access to APIs

In the approved Google Cloud project, have the owner confirm the Admin SDK/Directory access required by the connector. For FileWave 15.4.0 and later, Enable Required Firebase APIs for Chromebook Management explicitly requires Firebase Management API (firebase.googleapis.com) and Firebase Cloud Messaging API (fcm.googleapis.com) in that same project. Confirm the selected project before enabling either service, then verify the result through Central's Google synchronization status.

Legacy enablement list — review only, not a one-click prerequisite. The previous procedure enabled admin, calendar, classroom, drive, driveactivity, gmail, groupssettings, licensing, plus, contacts and both Firebase services together. The literal URL is retained for integration-owner comparison:

https://console.developers.google.com/flows/enableapi?apiid=admin,calendar,classroom,drive,driveactivity.googleapis.com,gmail,groupssettings,licensing,plus,contacts,firebase.googleapis.com,fcm.googleapis.com

Do not use this broad list as permission approval. Enabling an API and granting OAuth access to data are different steps; enabling Gmail API alone does not grant mailbox access. Current sources do not establish that every service in this older list is needed. If your release needs more than the documented services, have the SE and Google owner resolve the list before proceeding. The older low-resolution animation of this broad-enablement workflow is omitted; the sequence and exact list remain here for review.

Create a service account and protect its credentials

After the owner approves the required IAM configuration:

1. In Google Cloud, open APIs & Services → Credentials → Create Credentials → Service Account.
2. Give the service account a recognizable name. It may match the project name, but does not have to. Select Create and Continue.
3. Apply only the role configuration approved for the supported FileWave release. The older recipe specified Basic → OWNER. That broad grant is retained as a review item, not a verified minimum or an instruction to grant it. Do not substitute a guessed narrower role either. Stop here if the Google owner and SE have not resolved the required roles.
4. Complete the remaining creation prompts; the older flow used Continue, then Done, with no additional access grant in the final section.
5. If an exported key is approved, open Manage Service Accounts → [the intended account] → Manage keys → ADD KEY → Create New Key and download the JSON key. If organization policy blocks keys, stop for a supported alternative; do not disable the policy.

Keep that service-account JSON in approved secret storage and transfer it only through the intended FileWave import. It contains private credentials. Do not paste it into tickets, email threads, screenshots or the Google extension-policy editor.

Delegated user and service-account access

The older recipe used Manage service accounts, selected the account, then MANAGE ACCESS → ADD PRINCIPAL, entered the intended Google user, and assigned Service Account User plus Service Account Token Creator, then SAVE. These exact role choices are preserved for the Google owner's release-specific review. They are not proven minimum runtime permissions and are not equivalent to Google Workspace administrator privileges or domain-wide delegation. Do not grant them merely because the user will be entered in Central.

Have the owner confirm the intended delegated Google identity, its necessary Workspace privileges and whether these IAM grants are actually required before continuing.

OAuth Client ID and domain-wide delegation

In IAM & Admin → Service Accounts, open the intended account's details (Manage Details in the older action menu), expand Advanced settings, and copy the Client ID under Domain-wide Delegation. This is the service account's client identifier, not its private key and not its display name.

The Google super administrator performs this step, following Google's domain-wide delegation instructions:

1. Open Google Admin Console, then Security → Access and data control → API controls → Manage Domain Wide Delegation.
2. Select Add new and enter the copied Client ID. Older instructions called this field Client Name; Google's current documentation calls it Client ID.
3. Review the required OAuth Scopes (older label: One or More API Scopes) against the supported FileWave configuration. The original FileWave recipe lists:

https://www.googleapis.com/auth/admin.directory.device.chromeos, 
https://www.googleapis.com/auth/admin.directory.customer, 
https://www.googleapis.com/auth/admin.directory.orgunit

4. Only after approval, authorize the agreed scopes. Complete any multi-party approval required by the organization. Open the client entry's View details and confirm every approved scope is listed. Google says changes can take up to 24 hours, though they usually propagate sooner.

These are write-capable directory scopes, not a promise of read-only integration. Google's device-list API also supports a read-only scope and OU query parameters, but that does not establish a supported read-only or OU-filtered FileWave connector. Do not silently replace the documented scope list or assume an extension-policy OU limits domain-wide delegation. If permission requirements are still unclear, ask the SE and Google owner to resolve them rather than trying additional grants.

Import into FileWave and check setup success

1. Confirm the ChromeOS Firebase/API and delegated-account setup above is complete and approved.
2. Open FileWave Central → Preferences → Google. Older screenshots call the application FileWave Admin; some references call Preferences Settings.
3. In OAuth 2.0 Service Account, select Configure OAuth token and complete the prompted authentication with authorized access.
4. Enter the intended delegated Google Account, then import the service-account JSON key from the credentials step—not the Android activation JSON and not an exported extension policy.
5. Check the account/project identity before selecting OK. The documented workflow starts synchronization automatically; this can import the full Google Chromebook list, not just your test OU.
6. Wait for a successful Google sync status and note the Last synchronization time. If devices were already enrolled, inspect Clients → Chromebooks for the Google OU structure and match the known test serial number. A large first import can take time; do not change server timeout settings yourself to hurry it.

Setup succeeds when the intended integration has a successful synchronization and the expected Google-derived records, within the approved license scope. If the test device is not yet enrolled, finish that checkpoint in Chromebook Enrollment. A green connector status alone does not prove direct extension communication.

Optional: deploy the FileWave Inventory Extension

Skip this section if your first goal is Google-synchronized inventory only. For additional device inventory, agree on the policy scope for the test user and device, and verify inherited settings before changing Google policy. Keep location collection off unless separately approved.

1. In Central, open Preferences → Google, find Chromebooks Extension, and select Export Policy for Extension. Older instructions refer to this as the Google/Chromebooks tab.
2. Store the export securely. This extension-policy JSON is not the service-account key. It can include an inventory token and server/FCM settings; do not publish its contents or send the key JSON to endpoints.
3. In Google Admin Console, open Devices → Chrome → Apps & Extensions → Users & browsers.
4. Select the approved policy OU. Use + → Add Chrome app or extension by ID and enter ldhgnmkjehdokljjhcpkbhcmhoficdio. Select Save.
5. Open Policy for extensions and upload the JSON exported in step 1 of this section. Save the policy.
6. Set the approved installation policy to Force install or Force install + pin to the browser toolbar, then save. Verify the effective extension policy reaches the intended signed-in user and device; selecting a similarly named OU is not proof. Have the Google administrator resolve user/device OU inheritance rather than applying the policy at the domain root to make it work.
7. On the known test Chromebook, sign in as the approved managed user, keep the device awake and connected, and open Chrome. In chrome://policy, inspect ExtensionInstallForcelist for the extension ID and the FileWave policy section. Do not change policy or enable developer tools merely to read inventory.
8. Allow the extension's reporting schedule to run. In FileWave, inspect that same serial-number record for extension-derived inventory and Last Connected. The extension needs an installed, signed-in user context, Chrome open, and network access to FileWave. A Google sync by itself does not force a fresh extension report.

If those extension results are missing, first check the effective policy, confirm that the policy export and server identity are correct, and check user context, connectivity and certificate trust. Use ChromeOS communication troubleshooting with the owner for deeper diagnostics. Do not share tokens in console logs or exports.

Optional: changing check-in frequency

The extension-policy attribute below controls reporting in minutes. The documented default is 1440, once per day. Keep the default for the first exercise unless the owner approves a different interval and its reporting load. This is separate from Central's Google Admin synchronization schedule; Google Admin Sync Interval documents a default of 24 hours and a configurable range of 1–24 hours.

"UpdateIntervalInMinutes": {
"Value": 1440
}

This is the original policy excerpt, not a complete upload file. Edit only the intended value in a valid export and have the owner validate the JSON before saving a policy change.

Optional: location tracking permissions

Location collection is not required to prove enrollment or inventory. Obtain organizational privacy approval first, including who can view the data and the allowed collection scope. In the documented Google interface, use Devices → Chrome → Settings → User & Browser Settings, then Security → Geolocation → Allow sites to detect Users' geolocation. Confirm the effective policy reaches the intended user and device; do not apply it domain-wide as a troubleshooting shortcut.

Older interface example with Foundry Chromebooks selected. The menu shows the geolocation option, not proof that it was saved. Its User & Browser Settings tab does not establish the effective policy on the device or other OUs. Domain-level settings can be inherited, and child OUs can override them; review those settings with the Google administrator.

Next: complete Chromebook Enrollment, match the Google and FileWave identities, and read the inventory available for that device. Stop there before considering any OU move, annotated-field write, remote action or location test.

If the result is missing

Check the intended Google organization, Chromebook provisioning state, FileWave activation, project/service-account identity, Google synchronization status and last successful sync time first. For extension-only gaps, check the signed-in user's effective policy and reporting conditions. Do not reset a device, recreate the connector, broaden permissions or run a Model Update just to make a record appear.

Chrome Troubleshooting Guide includes deeper logs and self-managed server procedures; those are owner-led diagnostics, not extra beginner steps. Verify/Refresh Inventory can process device work and is not a passive screen refresh. This read-only outcome needs neither Verify nor a Model Update. If a later approved action requires a Model Update, use the shared model-change lesson: review pending work beforehand because the commit is shared and its dialog is confirmation only.