Academy
Technical · Course T6

Lesson 4 of 4

WeSupport and WeShield: fix and protect

8 min read
In this lesson you'll learn to
  • Run admin- and user-initiated WeSupport sessions end to end
  • Explain the green/red call distinction and the annotation trade-off
  • Configure WeShield's four protection areas and platform update controls

The last pair turns WeGuard from visibility into intervention: WeSupport puts an admin's eyes and hands on any online device, and WeShield hardens the fleet against threats — with update controls keeping the whole estate current on your schedule.

WeSupport: remote sessions

WeSupport is a Pro app, installed by policy: App Management → Pro → enable WeSupport, save, and devices pick it up on the next sync. Everything about it follows one rule — the device must be online. There is no offline queue; a session drops the moment connectivity does.

Admin-initiated: Devices → pick an online device → WeSupport tab → Connect to Device → the user accepts the screen-share prompt → live session with screen view, full remote control, bidirectional voice, file transfer, and chat fallback.

User-initiated: the device's WeSupport app has two call buttons, and the difference is worth teaching every customer:

  • Green — notifies available admins. Normal support.
  • Red — notifies all admins and bypasses Do Not Disturb. The emergency path; "red calls reached a DND admin" is expected behavior, not a bug.

Session extras: annotations let both sides draw on the live screen — and deliberately suspend remote control while active (the Enable User Control toggle resumes it); auto-answer can connect sessions without a per-call prompt, though the user keeps the on/off switch and first-time casting permission is always required. Every session logs to a call-information dashboard — device, attending admin, timestamps, duration, direction — and sessions are end-to-end encrypted with full audit logging, which answers the security questionnaire before it's asked.

WeShield: endpoint protection

WeShield concentrates on Windows, where it appears as its own tab in the policy editor with four configuration areas:

  • General — notification and reporting behavior.
  • Antimalware — real-time protection, scan schedules, exclusions.
  • Network Protection — firewall rules and network security.
  • Device Control — USB and peripheral restrictions.

Its device-side tabs (notification, communication, update) can be individually hidden from users via the Windows policy. On Android, the equivalent hardening lives in the policy's Malware Protection section — a Work Managed/Kiosk-only section that locks down the settings malware abuses: unknown sources, safe boot, factory reset, developer options, hotspot, and manual date/time changes.

Updates on your schedule

Patch posture rides the policy engine rather than a separate console: Android policies carry a System Update control plus FOTA (firmware-over-the-air) allow/block toggles, and Windows policies carry update settings in their General section. The operating principle to position: updates are a policy decision — staged, controlled, reversible — not something 3,000 devices decide for themselves on a Tuesday. For customers with deeper patch-pipeline requirements, loop in the WeGuard team on current Patch Management capabilities rather than improvising a promise.

That completes the suite: track it, supply it, talk to it, fix it, protect it — one console, one enrollment, one invoice.

Knowledge check
1. The one non-negotiable precondition for any WeSupport session is…
2. A device user hits the red call button. What happens?
3. During a session you enable annotations to circle a setting, and remote control stops working. Why?