Plan and complete a GuardSphere deployment across ChromeOS, Android, Windows, or a mixed device environment.
This guide explains the journey from deployment preparation and Device Agent installation through enrollment, policy synchronization, verification, and ongoing governance. It is designed for families, schools, enterprises, institutions, and other authorized organizations managing supported devices.
Detailed, organization-specific deployment progress remains available in the authenticated GuardSphere Deployment Assistant after an organization account has been created.
Select the path that matches the devices you plan to manage. Organization type does not limit platform choice. A family, school, enterprise, or institution may deploy any supported platform that fits its environment.
Deploy the GuardSphere ChromeOS Extension centrally through Google Workspace using Force Install.
After installation, an authorized school administrator or delegated IT staff member opens the extension on each managed Chromebook and completes enrollment before the device is issued to a student.
Install the GuardSphere Android Device Agent and enroll each device into the appropriate GuardSphere organization and group.
GuardSphere supports multiple enrollment methods. The detailed Android section explains how administrators choose the appropriate method for their rollout.
Install the GuardSphere Windows Device Agent and complete enrollment before the computer enters active use.
Windows deployment can be used by families, schools, enterprises, institutions, and other supported organization types.
Deploy ChromeOS, Android, and Windows devices within the same GuardSphere organization.
A mixed deployment provides one administrative environment for device visibility, policy assignment, governance, reporting, and operational review.
Although installation differs by platform, every successful GuardSphere rollout follows the same operational lifecycle. Administrators should verify a pilot deployment before expanding to larger groups of devices.
Confirm organization access, administrators, groups, users, device capacity, and rollout responsibilities.
Install the correct GuardSphere Device Agent or centrally deploy the ChromeOS Extension.
Connect each device to the correct GuardSphere organization and deployment group.
Confirm that the device appears correctly, checks in, receives policy, and begins reporting expected signals.
Review policy activity, device health, governance information, reporting, and rollout readiness.
Refine policies and expand deployment only after the pilot environment behaves as expected.
GuardSphere administrators create enrollment access from the device enrollment page. The administrator chooses the method that fits the device, rollout size, and operational environment.
The currently available methods are QR, Link, Code, Email, and NFC. Because NFC is marked as not reliable in the current product, it should not be treated as the primary method for a production deployment.
Installing the GuardSphere Device Agent or ChromeOS Extension does not by itself connect the device to an organization. Enrollment completes that connection and should be verified before the device enters normal use.
Creates a QR-based enrollment option that can be used during device enrollment.
Creates a link-based enrollment option that can be opened on the device being enrolled.
Creates a code-based enrollment option for workflows where an enrollment code is entered on the device.
Creates an email-based enrollment option for delivering enrollment access through email.
NFC appears as an available enrollment method in GuardSphere, but it is currently marked as not reliable and should not be the primary production enrollment method.
Current guidance: Use QR, Link, Code, or Email for a production rollout unless NFC reliability has been separately verified for the intended deployment.
For managed environments, an authorized administrator or delegated deployment staff member should complete and verify enrollment. This reduces the risk that a device is issued without being connected to GuardSphere.
Continue to the ChromeOS deployment guide for Google Workspace Force Install, administrator-led enrollment, pilot verification, and the rollout sequence for managed Chromebooks.
The recommended ChromeOS deployment path is centralized installation through Google Workspace. The school or organization uses Google Workspace Admin to force-install the GuardSphere ChromeOS Extension on managed Chromebooks.
Force installation places the extension on the Chromebook, but the device must still be enrolled into the correct GuardSphere organization and group. An authorized administrator or delegated IT staff member should complete and verify that enrollment before the device is issued to a student or other user.
Prepare groups and policies before enrolling devices. Begin with a small pilot, verify that the extension and GuardSphere telemetry are operating correctly, and only then expand deployment to additional organizational units or Chromebook groups.
Create the organization, confirm access, create the required groups, add administrators, and prepare policies before deploying the extension.
Confirm that the Chromebooks are enterprise-enrolled and placed in the correct Google organizational units for the intended rollout.
Use Google Workspace Admin to deploy the GuardSphere ChromeOS Extension to the selected organizational unit.
An authorized administrator or delegated IT staff member should open the installed GuardSphere extension on each managed Chromebook.
Enroll the Chromebook into the correct GuardSphere organization and group using a supported enrollment method.
Confirm that the Chromebook appears in GuardSphere, checks in, receives the intended policies, and begins reporting the expected browser and domain signals.
Test the deployment with a limited class, grade, staff group, or Chromebook cart before expanding to the full fleet.
The administrator or delegated deployment staff should open the installed extension and complete enrollment on every managed Chromebook. This ensures that the device is connected to GuardSphere and protected by the intended policies before normal student use.
Force installation and GuardSphere enrollment are separate stages. The presence of the extension alone does not confirm that the Chromebook has been enrolled into the organization.
Delivers and maintains the GuardSphere ChromeOS Extension on the selected managed Chromebooks.
Connects the Chromebook to the correct GuardSphere organization, group, policies, device record, and administrative workflow.
Continue to the Android deployment guide to compare DPC and normal deployment, review supported enrollment choices, verify the device, and complete a controlled pilot rollout.
GuardSphere supports two Android deployment approaches: DPC deployment and normal Device Agent deployment. The correct choice depends on who owns the device, how much management authority the organization requires, and what level of control has been authorized.
DPC deployment is intended for fully managed devices. Normal deployment is intended for environments that require GuardSphere protection and reporting without giving GuardSphere full management authority over the Android operating system.
Review both options before beginning the rollout. The selection should be based on device ownership and authorized management needs, not simply on which option provides the most control.
GuardSphere operates as the Device Policy Controller and receives full management authority over the enrolled Android device.
Organization-owned or fully managed Android devices where the administrator requires strong control over the device.
Important: Choose this mode only when the organization is authorized to fully manage the device and users have been informed of the management arrangement.
GuardSphere is installed as a standard Android Device Agent and uses the permissions enabled for that deployment.
Devices where GuardSphere should provide protection, policy enforcement, and reporting without taking full management control of the Android operating system.
Important: The available protection and reporting depend on the permissions granted and the capabilities enabled on the device.
In a GuardSphere DPC deployment, the user cannot uninstall the Device Agent without an administrator-provided uninstall code. This helps ensure that a fully managed device remains under the organization's approved management and protection.
Cannot independently remove GuardSphere from the fully managed device.
Authorizes removal by providing the appropriate administrative uninstall code.
Security-sensitive removal actions should remain administrator-authorized and auditable.
The organization must ensure that full device management is authorized and appropriate.
Confirm that the organization owns or is authorized to fully manage the Android device before beginning DPC enrollment.
Create the intended GuardSphere group and assign the required policies before enrolling the device.
Begin the supported GuardSphere DPC installation or managed-device provisioning process on the target Android device.
Connect the device to the correct GuardSphere organization and group using a supported enrollment method.
Complete the device-management and permission setup required by the GuardSphere DPC deployment.
Confirm that the device appears in GuardSphere, checks in, receives policies, and begins reporting the expected signals.
Create the intended group, prepare policies, and confirm that the organization has capacity for the Android device.
Install GuardSphere on the target Android phone or tablet using the available distribution route.
Use QR, Link, Code, Email, or another currently supported and verified enrollment method.
Connect the device to the correct GuardSphere organization and group.
Grant the permissions needed for the intended protection, reporting, location, accessibility, or network-control features.
Confirm that the Android device checks in, receives policies, and begins reporting the expected telemetry.
Choosing DPC or normal deployment determines the Android management model. The administrator must still complete GuardSphere enrollment using a currently supported enrollment method such as QR, Link, Code, Email, or NFC where separately verified.
Continue to the Windows deployment guide for Device Agent installation, enrollment, service activation, policy synchronization, authorized uninstall, verification, and pilot rollout.
GuardSphere supports managed Windows computers used by families, schools, enterprises, institutions, and other authorized organizations. The Windows deployment path combines the Device Agent, enrollment utility, background service, policy synchronization, and administrator-authorized uninstall workflow.
Installation alone does not complete deployment. The computer must be enrolled into the correct GuardSphere organization, the Windows service must be running, and the administrator must verify that the device is checking in and receiving the intended policy.
The Windows deployment uses several cooperating components rather than a single visible application. Administrators should understand these components before testing installation, operation, and authorized removal.
The primary GuardSphere component responsible for running the managed-device workload on the Windows computer.
Runs the GuardSphere background workload, maintains device communication, and supports policy synchronization and reporting.
Provides the administrator-facing process used to connect the Windows computer to the appropriate GuardSphere organization.
Provides the approved administrative path for removing GuardSphere from a managed Windows computer.
Supports verification of administrator-authorized removal before protected GuardSphere components are removed.
After the Windows Agent is installed and enrollment succeeds, the service maintains the device connection, synchronizes applicable policies, and reports supported device information to the GuardSphere platform.
Begin with one or a small number of computers. Verify service operation, policy synchronization, reporting, and authorized uninstall before expanding deployment to additional users or groups.
Confirm organization access, device capacity, groups, administrators, and policies before installing the Windows Device Agent.
Install the approved GuardSphere Windows package on the target computer. Public Microsoft Store distribution will be linked when the Store release is available.
Use the GuardSphere Windows Enrollment utility to begin connecting the computer to the correct organization.
Use a supported enrollment method and ensure that the device is associated with the intended GuardSphere organization and group.
Verify that the GuardSphere Windows service is installed, running, and able to communicate with the GuardSphere platform.
Confirm that the computer receives the intended policy and begins reporting heartbeat, device status, and supported enforcement information.
Validate installation, enrollment, policy behavior, reporting, and authorized uninstall on a small number of computers before wider deployment.
GuardSphere removal from a managed Windows computer should be an administrator-authorized action. The approved uninstall path uses the GuardSphere Authorized Uninstall and verification components rather than relying on direct removal of protected files or services.
Do not test tamper protection by manually deleting GuardSphere files, registry state, or services. Use the supported administrator-authorized workflow so that removal remains controlled and auditable.
A missing device, delayed check-in, or policy issue does not always require reinstallation. Confirm enrollment, service state, organization assignment, network communication, and policy assignment first.
Confirm enrollment completed successfully and that the device was connected to the intended organization.
Check that installation completed correctly and confirm the GuardSphere Windows service state.
Confirm network access, service activity, and the device enrollment state before reinstalling anything.
Confirm that the device or its group has the intended policy assignment and that synchronization has completed.
Use the administrator-authorized uninstall workflow rather than attempting to remove protected components directly.
Continue to the mixed deployment guide to coordinate ChromeOS, Android, and Windows within one GuardSphere organization using shared groups, policies, enrollment planning, verification, and phased rollout.
A mixed deployment brings supported device platforms into the same GuardSphere organization while preserving the correct installation, enrollment, verification, and operating process for each platform.
GuardSphere groups and policies provide shared organizational structure, but platform-specific deployment differences still matter. ChromeOS uses Google Workspace deployment, Android requires a choice between DPC and normal deployment, and Windows uses the Windows Device Agent and service architecture.
Each supported platform follows its own installation and verification path, then reports into the same organization for device visibility, policy assignment, governance, and operational review.
A mixed deployment should not collapse every platform into one generic checklist. Complete installation, enrollment, and verification according to the actual requirements of each platform.
Deploy the GuardSphere ChromeOS Extension through Google Workspace Force Install.
An authorized administrator or delegated IT staff member opens the extension and completes enrollment.
Confirm extension presence, device registration, recent activity, policy assignment, and browser or domain reporting where enabled.
Choose DPC deployment or normal Device Agent deployment based on ownership and authorized management requirements.
Complete enrollment using one of the currently supported enrollment methods.
Confirm permissions, policy synchronization, recent activity, expected telemetry, and uninstall protection where DPC is used.
Install the GuardSphere Windows Device Agent using the approved distribution package.
Use the Windows enrollment utility to connect the computer to the correct organization and group.
Confirm service operation, heartbeat, policy synchronization, reporting, and the administrator-authorized uninstall path.
The safest mixed deployment starts with accurate inventory, organization structure, and separate platform pilots. Expand only after each deployment path has been independently verified.
Identify which ChromeOS, Android, and Windows devices will be managed, who owns them, and which groups or departments they belong to.
Create GuardSphere groups that reflect classes, departments, households, teams, locations, or device ownership before enrollment begins.
Create and assign policies at the organization or group level while accounting for platform-specific enforcement differences.
Use Google Workspace for ChromeOS, select DPC or normal deployment for Android, and install the Windows Device Agent for Windows computers.
Generate enrollment access for the correct platform and group rather than using one unstructured invite for the entire rollout.
Verify a small ChromeOS, Android, and Windows pilot before combining the results into a broader production rollout.
Confirm that devices from every platform appear in the same organization with correct groups, policies, health, and recent activity.
Roll out by platform, group, department, class, household, or location only after the corresponding pilot is stable.
GuardSphere policies belong to the organization and can be assigned to groups and devices. However, the effective behavior of a policy may depend on the capabilities and permissions available on the target operating system.
Verify the actual result on each platform before treating a policy as production-ready for the entire mixed fleet.
Mixed environments become difficult when platform differences, ownership, group structure, and verification are ignored. Preserve clear deployment boundaries even though administration is unified.
Avoid using a single unstructured enrollment invite across unrelated platforms and groups. Separate invites make assignment and troubleshooting clearer.
A shared policy model does not mean every operating system enforces every control in exactly the same way.
A successful ChromeOS pilot does not automatically confirm that Android or Windows deployment is ready.
Especially on Android, device ownership and authorized management level determine whether DPC or normal deployment is appropriate.
Create groups before enrollment so devices do not accumulate without clear policy or administrative ownership.
Every platform still requires enrollment, policy synchronization, recent activity, and operational verification.
Continue to the shared verification framework for all deployment scenarios, including pilot readiness, device check-in, policy confirmation, telemetry review, rollout approval, and production expansion.
A successful GuardSphere deployment is not measured only by whether the Device Agent or Extension was installed. Administrators must confirm enrollment, device communication, policy behavior, reporting, permissions, and operational readiness before expanding to a larger device population.
The pilot should be small enough to troubleshoot safely but realistic enough to represent the intended production environment. Mixed deployments should maintain separate platform checks even when the devices belong to the same organization.
Complete each stage before treating the pilot as production-ready. Do not allow a successful installation to hide unresolved enrollment, policy, telemetry, permission, or support problems.
Choose a limited class, department, household group, staff group, location, device cart, or small device set that represents the intended production environment.
Create the required groups, managed people, administrators, scopes, policies, and assignments before enrolling the pilot devices.
Complete the correct platform-specific installation and enroll every pilot device into the intended GuardSphere organization and group.
Verify that every pilot device appears in GuardSphere, reports a recent last-seen or heartbeat time, and remains connected during normal use.
Confirm that intended policies synchronize and that allowed, blocked, scheduled, or monitored activity behaves as expected on each platform.
Inspect device activity, logs, policy decisions, telemetry, governance information, and reports that apply to the selected deployment.
Correct enrollment, group assignment, permission, service, policy, reporting, or operational problems before approving expansion.
Expand only after the responsible administrator confirms that the pilot is stable, documented, supportable, and appropriate for broader deployment.
These checks should be completed before the first pilot device is enrolled.
These checks provide evidence that the pilot is stable enough for the next rollout phase.
Each rollout phase should produce enough operational evidence to justify the next one. Device count should increase only after the current group is stable and supportable.
Deploy to a very small number of devices managed by administrators or trusted pilot users. Confirm installation, enrollment, check-in, policy synchronization, and reporting.
Expand to one representative group, class, department, family group, device cart, or location. Observe normal use and resolve operational issues.
Add more groups or locations in manageable batches. Review device health, policy behavior, and support demand after each batch.
Complete the wider deployment only after earlier phases are stable and administrators can support enrollment, verification, policy review, and authorized removal.
Continue reviewing device status, policy outcomes, logs, governance evidence, usage insight, reports, and changing organizational needs.
A temporary pause is safer than multiplying an unresolved issue across many devices. Investigate and verify the current state before adding another rollout group.
Pause expansion if expected devices do not appear in GuardSphere after enrollment.
Do not expand while devices have inconsistent heartbeat, last-seen, or service activity.
Pause if administrators cannot confirm which policy applies or why a device is behaving differently from expectations.
Do not rely on reports or governance conclusions until the expected platform signals are actually appearing.
Resolve missing Android permissions, ChromeOS extension state, Windows service issues, or other platform-specific setup differences.
Administrators should understand authorized uninstall and unenrollment before a protected deployment is expanded.
Device governance requires regular review. Administrators should confirm that devices remain connected, policies remain appropriate, reporting remains useful, and new operational risks are addressed.
The authenticated Deployment Assistant provides organization-specific progress tracking and readiness detection after an organization has been created.
Continue to answers about installation, enrollment, platform choice, administrator responsibility, device ownership, mixed environments, authorized uninstall, pilot rollout, and the authenticated Deployment Assistant.
Review answers about platform choice, installation, enrollment, administrator responsibility, device ownership, Android management, Chromebook deployment, Windows removal, mixed fleets, pilot verification, and production rollout.
After creating an organization, authenticated administrators can use live readiness checks, saved progress, and direct links to the tools required for their actual rollout.
This guide documents verified GuardSphere deployment behavior. Product capabilities, store availability, permissions, and deployment workflows should be updated here whenever the actual implementation changes.
Choose according to the devices you need to manage. Use the ChromeOS path for managed Chromebooks, the Android path for Android phones and tablets, the Windows path for Windows computers, and the mixed deployment path when one organization manages more than one supported platform.
No. Platform choice is based on the devices being managed, not only on organization type. A family may manage Android and Windows devices, a school may manage ChromeOS, Android, and Windows devices, and an enterprise or institution may also operate a mixed fleet.
No. Installation places the GuardSphere software on the device, but enrollment connects that device to the correct GuardSphere organization and group. Administrators must also verify device check-in, policy synchronization, and expected reporting before considering deployment complete.
The current GuardSphere device enrollment page provides QR, Link, Code, Email, and NFC. NFC is marked as not reliable in the current product and should not be treated as the primary method for a production rollout unless it has been separately verified for the intended environment.
No. After the GuardSphere ChromeOS Extension is force-installed, an authorized school administrator or delegated IT staff member should open the extension and complete enrollment on each managed Chromebook before the device is issued to a student.
No. Google Workspace delivers and maintains the ChromeOS Extension on selected managed Chromebooks. GuardSphere enrollment is a separate step that connects the Chromebook to the correct organization, group, policies, device record, and administrative workflow.
The documented centralized ChromeOS deployment path uses Google Workspace Force Install for managed Chromebooks. Android and Windows devices follow their own deployment paths. Any alternative ChromeOS installation workflow should be verified against the current product and the school's device-management environment before rollout.
DPC deployment gives GuardSphere full device-management authority and is intended for devices the organization is authorized to fully manage. Normal deployment installs GuardSphere as a standard Device Agent and provides protection, enforcement, and reporting according to the permissions and capabilities enabled on the device.
Use DPC deployment when the device is organization-owned or otherwise authorized for full management, and when the organization requires stronger device-level control and protected removal. The organization should confirm ownership, authority, user notice, and operational responsibility before selecting this mode.
A user cannot uninstall GuardSphere from a DPC-managed device without an administrator-provided uninstall code. Removal should remain an administrator-authorized and auditable action.
Normal Android deployment depends on the permissions granted and the product capabilities enabled on the device. Administrators should verify the intended protection, policy, usage, accessibility, location, network, and reporting behavior during the pilot rather than assuming all signals are active.
GuardSphere should be removed through the administrator-authorized uninstall workflow. The Windows architecture includes authorized-uninstall and verification components so removal can remain controlled rather than relying on direct deletion of protected files, registry state, or services.
The intended public distribution route is the Microsoft Store. Until the Store release is available, the public Deployment Guide should display Windows as coming soon rather than link visitors to an unavailable listing.
The Android Device Agent is intended for Google Play distribution. Until the public Play Store listing is available, the landing page and Deployment Guide should present Android as coming soon rather than provide a non-public download route.
Yes. ChromeOS, Android, and Windows devices can coexist in the same GuardSphere organization. They can share organization structure, groups, policy assignments, administrative visibility, governance, and reporting while retaining platform-specific installation, permission, telemetry, and removal requirements.
Not necessarily. Policies are managed within the GuardSphere organization, but effective enforcement can depend on the capabilities, services, permissions, and operating-system controls available on each platform. Administrators should verify policy behavior separately on every deployed platform.
Separate enrollment invites are preferable when platforms, groups, classes, departments, households, or deployment batches differ. Clear invite boundaries improve assignment, rollout control, verification, and troubleshooting.
Creating groups first allows devices to join the correct class, department, household, team, location, or device cohort from the beginning. This reduces unassigned devices, avoids cleanup work, and helps ensure the intended policies apply immediately.
Assigning policies before enrollment helps newly enrolled devices receive the intended rules during their first synchronization. Administrators should still verify the actual policy assignment and enforcement result after the device checks in.
The pilot should be small enough to troubleshoot safely but realistic enough to represent the intended environment. It may use a small class, department, household group, staff group, device cart, location, or limited set of administrator-controlled devices.
A pilot is ready when expected devices are enrolled, correctly grouped, recently seen, receiving the intended policies, producing expected signals, and operating without unresolved issues that would become harder to correct at greater scale. Administrators should also understand support and authorized-removal procedures.
Pause when devices are missing, check-in is unreliable, policy assignment is unclear, expected telemetry is absent, platform permissions are inconsistent, or administrators do not understand the supported uninstall or unenrollment process. Resolve and verify the current state before adding more devices.
Authenticated administrators gain access to the GuardSphere Deployment Assistant. It provides organization-specific progress tracking, readiness detection, operational checklists, and direct links to groups, users, policies, enrollment, devices, Google Workspace, geofences, governance, workforce tools, reporting, and billing.
No. The public guide helps prospective and new administrators understand deployment scenarios before signing in. The authenticated Deployment Assistant uses the organization's actual configuration and progress to guide its operational rollout after account creation.
A pilot is strongly recommended. It allows administrators to validate installation, enrollment, communication, permissions, policy behavior, reporting, and removal procedures without exposing the entire fleet to an unresolved deployment issue.
Deployment continues after enrollment. Administrators should regularly review device connectivity, group placement, policy assignments, enforcement decisions, expected telemetry, governance information, reports, failed workflows, support cases, and required adjustments.
Start with a controlled pilot, verify the selected platform path, and use the authenticated Deployment Assistant to track readiness as your GuardSphere rollout progresses.
Create an organization to begin deployment, book a demonstration, or return to the main GuardSphere website.
