Zugriff auf lokale Computer für Work Cloud und dots
Work und dots können zulässige Dateien und Tools auf einem verbundenen Computer verwenden, während die Cloud von OpenAI die Aufgabe koordiniert. Aktivieren Sie den Zugriff auf lokale Computer für jede Funktion separat.
Lesen Sie zunächst die folgenden gemeinsamen Hinweise zu Richtlinien, Kompatibilität und Audits. Folgen Sie anschließend den Einrichtungs- und Benutzerhinweisen für Work oder dots, je nachdem, welche Funktion Sie aktivieren möchten.
Dieser Leitfaden hilft Inhabern von Enterprise-Workspaces, Richtlinienanforderungen zu prüfen und den Zugriff auf lokale Computer für Work und dots zu aktivieren. Die Verfügbarkeit hängt von Ihrem Workspace und dem Rollout ab.
Informationen zur Global-Basiskonfiguration, zu umgebungsspezifischen Überschreibungen und zu den Feldlisten für Orchestrator und Executor finden Sie unter Agent Security.
Vorteile des Zugriffs auf lokale Computer
Wenn Sie den Zugriff auf lokale Computer in diesen Funktionen aktivieren, können Teams geräteübergreifend weiterarbeiten. Administratoren können unterstützte Anforderungen für die Ausführung auf einem lokalen Computer zentral in Agent Security verwalten. Diese Ausführungsanforderungen gelten nicht, wenn Work einen Cloud-Container oder ein dot einen Cloud-Computer verwendet. Für die Cloud-Ausführung gibt es separate Steuerelemente für Browserzugriff, Netzwerkzugriff und Computernutzung.
Work
Ein Work-Gespräch geräteübergreifend fortsetzen. Beginnen Sie auf einem Computer und prüfen Sie dann Ergebnisse oder geben Sie Folgeanweisungen über die Web- oder Mobil-App. Aufgaben, die mit Work Cloud auf lokale Computer zugreifen, werden in der Cloud koordiniert.
Freigegebene Ressourcen auf Ihrem Computer verwenden. Eine Aufgabe, die diese Funktion nutzt, kann über einen verbundenen Computer auf zulässige lokale Dateien und Tools zugreifen, während Sie den Fortschritt auf einem anderen Gerät verfolgen. Lassen Sie diesen Computer für Schritte, die ihn benötigen, online und verbunden.
Anforderungen an die lokale Ausführung zentral verwalten. Legen Sie unterstützte Enterprise-Anforderungen für die lokale Ausführung in Agent Security fest. Prüfen Sie die Work Cloud-Richtlinien für die Cloud-Ausführung separat.
Dots
Entwicklungsaufgaben lokal erledigen. Untersuchen Sie Fehler, implementieren Sie Änderungen und führen Sie Builds mit zulässigen lokalen Repositorys, Entwicklungstools und Skills aus.
Programmierarbeiten koordinieren. Erstellen Sie lokale Work- oder Codex-Threads und steuern Sie bestehende lokale Codex-Threads.
Desktop-Apps und den lokalen Browser für unterstützte Aufgaben verwenden, einschließlich Aufgaben, die eine lokale Anmeldung erfordern, wenn der Cloud-Browser sie nicht erledigen kann.
Vor und nach der Aktivierung des Zugriffs auf lokale Computer mit Work Cloud
Eine Aufgabe besteht aus zwei Teilen: Koordination und Ausführung. Die Koordination entscheidet, welche Schritte auszuführen sind, und führt das Gespräch weiter. Die Ausführung ist die Arbeit, die ein Tool erledigt, etwa das Ausführen eines Shell-Befehls. Diese Funktion verlagert die Koordination in die Cloud von OpenAI. Sie verlagert nicht alle Tools oder Dateien vom Computer.
| Bereich | Vor der Aktivierung dieser Funktion | Nach der Aktivierung dieser Funktion |
|---|---|---|
| Ein lokales Work-Gespräch fortsetzen | Mitglieder wählen einen lokalen oder einen Cloud-Thread in Work, sofern verfügbar. | Wenn Mitglieder Cloud auswählen, werden geeignete neue Gespräche in der Cloud koordiniert und können geräteübergreifend fortgesetzt werden. Wenn Mitglieder Local auswählen, erfolgen Koordination und Ausführung weiterhin lokal. Für Unternehmen bleiben der Local/Cloud-Schalter in der App und seine Standardeinstellung bei der Einführung unverändert. |
| Aufgabenkoordination | Der bisherige lokale oder Cloud-Workflow gilt. | Die Cloud von OpenAI koordiniert die Work-Aufgabe. |
| Schritte, die den Computer des Benutzers benötigen | Lokales Work kann die Tools und Dateien des Computers verwenden. Cloud-Work kann den Computer nicht verwenden. | Der Computer stellt diese Tools und Dateien weiterhin bereit und muss online und verbunden sein. |
| Enterprise-Anforderungen | Für lokales Work gelten die bestehenden lokalen Anforderungen und Vorrangregeln. | Für den verbundenen Computer gelten die Anforderungen an die lokale Ausführung. Unterstützte Global-Richtlinien gelten für die Cloud-Orchestrierung, wenn verwaltete Richtlinien aktiviert sind; Work-Cloud-Container verwenden ihre eigene Ausführungskonfiguration und eigene Anforderungen. |
| Steuerung der lokalen Ausführung | Unterstützte Geräte- und Betriebssystemkontrollen gelten. | Bei der lokalen Ausführung haben MDM-Anforderungen und bisherige Anforderungen für verwaltete Geräte Vorrang vor Agent Security. Die Systemanforderungsdatei ist nachrangig. |
| Codex | Das bestehende Codex-Verhalten gilt. | Verhalten und Gesprächsverlauf von Codex bleiben separat. |
Zugriff auf lokale Computer einrichten
Ihre Richtlinien in Agent Security prüfen
Wo Sie die Einstellungen prüfen
Öffnen Sie Admin-Konsole → Agent Security. Agent Security ersetzt Richtlinien und Konfiguration. Der Rollout erfolgt unabhängig vom Zugriff auf lokale Computer für Work und dots.
Richtlinieneinstellungen: Prüfen Sie die Global-Basiskonfiguration und alle Local-Überschreibungen. Belassen Sie Orchestrator-Steuerelemente, einschließlich Genehmigungen und Websuche, in Global; Umgebungen können diese nicht überschreiben. Verwenden Sie die dafür vorgesehenen UI-Steuerelemente, sofern verfügbar, einschließlich Allowed approval policies und Allowed web search modes, und TOML für andere unterstützte Felder. Unter Orchestrator- und Executor-Steuerelemente erfahren Sie, wo die einzelnen Einstellungen gelten.
Anforderungen und Standardwerte: Anforderungen setzen Grenzen, die Benutzer nicht überschreiben können. Standardwerte legen Ausgangswerte innerhalb dieser Grenzen fest und können eine Anforderung nicht außer Kraft setzen.
Funktionszugriff: Verwenden Sie Workspace-Einstellungen → Berechtigungen und Rollen. Der Zugriff auf lokale Computer muss für Work und dots separat aktiviert werden.
Was übernommen wird
Bei der Migration geeigneter bisheriger Cloud-Richtlinien werden deren Einstellungen in Global übernommen; Richtlinienzuweisungen und Reihenfolge bleiben erhalten. Prüfen Sie die migrierten Richtlinien in Agent Security und kontrollieren Sie Ihre aktuelle Einrichtung anhand der folgenden Tabelle. Wenn Sie Richtlinienaktualisierungen automatisieren, prüfen Sie auch die letzte Zeile. Migrationshinweise finden Sie unter Agent Security.
| Ihre aktuelle Einrichtung | Was Sie vor der Aktivierung dieser Funktion tun sollten |
|---|---|
| Bestehende Cloud-Richtlinien | Vergleichen Sie die migrierte Global-Basiskonfiguration mit den erforderlichen Kontrollen Ihrer Organisation. Dokumentieren Sie die Einstellungen und testen Sie anschließend, ob zulässige Aktionen erfolgreich ausgeführt und eingeschränkte Aktionen blockiert werden. |
| Ausschließlich über MDM bereitgestellte Richtlinien | MDM stellt Richtlinien auf Geräten bereit. Konfigurieren Sie vor der Aktivierung dieser Funktion unterstützte Enterprise-Anforderungen für die lokale Ausführung in Agent Security. Bei der lokalen Ausführung haben MDM-Anforderungen und bisherige Anforderungen für verwaltete Geräte weiterhin Vorrang vor Agent Security. |
| Terraform oder Skripte zur Richtlinienaktualisierung | Verwenden Sie die Richtlinien-API zur Verwaltung der Global-Einstellungen. Verwenden Sie die Agent Security-Oberfläche zur Verwaltung der Local- oder Codex Cloud-Einstellungen. Bestehende Global-API-Workflows bleiben nach der Migration verfügbar. Testen Sie Ihre Skripte und Terraform-Integrationen und vergewissern Sie sich, dass Richtlinienzuweisungen und Reihenfolge unverändert sind. |
Welche Richtlinie Vorrang hat
Diese Regeln gelten auf unterschiedlichen Ebenen. Jeder Pfeil unten führt von der höchsten zur niedrigsten Priorität.
Zwischen Richtlinien: Eine Richtlinie mit höherer Priorität hat Vorrang vor einer Richtlinie mit niedrigerer Priorität, auch wenn die nachrangige Richtlinie spezifischer ist.
Innerhalb einer Richtlinie: Für unterstützte Ausführungseinstellungen gilt: umgebungsspezifische Überschreibung → Global. Eine Umgebung ohne Überschreibung übernimmt die jeweilige Global-Einstellung.
Lokale Anforderungen: macOS-MDM-Anforderungen → als Anforderungen interpretierte bisherige
managed_config.toml-Felder → von Agent Security in der Cloud verwaltete Anforderungen → systemseitigerequirements.toml. Die MDM-Ebene gilt unter macOS; für Standardwerte gelten separate Konfigurationsregeln.
Für einige Anforderungen gelten feldspezifische Zusammenführungsregeln. Informationen zum Geltungsbereich von Richtlinien, zu unterstützten Feldern und zum Ausführungsbereich finden Sie unter Verwaltete Konfiguration und in der Konfigurationsreferenz.
Wie Richtlinien für Work und dots gelten
Das gemeinsame Verhalten von Work und dots mit lokalem Zugriff umfasst die folgenden Bereiche:
Aufgabenkoordination: Wenn verwaltete Richtlinien aktiviert sind, setzt der Cloud-Dienst, der die Aufgabe koordiniert, unterstützte Anforderungen aus Global in Agent Security durch, etwa Genehmigungsanforderungen und zulässige Websuchmodi.
Lokale Ausführung: Wenn ein Tool auf einem verbundenen Computer ausgeführt wird, setzt es unterstützte Anforderungen an die lokale Ausführung aus Agent Security sowie geltende Geräterichtlinien durch, einschließlich über MDM bereitgestellter Richtlinien, sofern unterstützt. Dazu können Dateisystem- und Netzwerkbeschränkungen gehören. Es gelten nur Felder, die der lokale Executor unterstützt; die Konfiguration eines Feldes in MDM oder in der lokalen
requirements.tomlgarantiert nicht, dass es lokal durchgesetzt wird.Cloud-Ausführung: Work-Cloud-Container und die Cloud-Computer von dots verwenden separate Ausführungskontrollen. Lokale Dateisystem- und Netzwerkbeschränkungen gelten nicht automatisch für diese Cloud-Umgebungen.
Um gemeinsame Cloud-Funktionen zu konfigurieren, öffnen Sie Admin-Konsole → Berechtigungen und Rollen → Workspace-Funktionen → Cloud-Computer-Funktionen. Diese Berechtigungen gelten sowohl für Work Cloud als auch für dots. Prüfen Sie Cloud browser use und Cloud network access separat; die Konfiguration einer Option konfiguriert nicht die andere. Global-Richtlinien und Codex Cloud-Überschreibungen konfigurieren diese Berechtigungen nicht.
Kompatibilität und Datenanforderungen prüfen
Prüfen Sie vor der Aktivierung einer der beiden Funktionen die Voraussetzungen, den Umfang des Datenschutzes und die Kontrollen, auf die sich Ihre Organisation verlässt. Eine gemeinsame Infrastruktur bedeutet nicht, dass Work und dots dieselben Funktionen unterstützen.
Voraussetzungen für Work und dots prüfen
Work: Residenz gilt nur für berechtigte Inhalte sowie unterstützte Workloads, Regionen und Konfigurationen. EKM deckt unterstützte gespeicherte Inhalte in berechtigten Workspaces ab. Vergewissern Sie sich, dass Ihr Workflow abgedeckt ist, statt anzunehmen, dass jeder Schritt mit lokalem Zugriff oder jede verbundene Integration abgedeckt ist. Work wird mit Inferenzresidenz in den VAE nicht unterstützt. Siehe Datenresidenz und Inferenzresidenz und Work-Cloud-Sicherheit.
Residenz bei dots: Während der Enterprise-Beta unterstützen dots weder Datenresidenz noch Inferenzresidenz. Berechtigte Workspaces können dots aktivieren, nachdem sie diese Einschränkungen bestätigt haben; durch die Aktivierung werden die Daten oder die Verarbeitung von dots nicht residenzkonform.
Ausschlüsse bei dots: Dots sind für FedRAMP-Workspaces, Workspaces mit EKM und Workspaces mit Inferenzresidenz AE (VAE) nicht verfügbar. HIPAA-Workspaces können teilnehmen, wenn sie die übrigen Voraussetzungen erfüllen.
Datenverarbeitung und Schutzmaßnahme für lokalen Zugriff prüfen
Cloud-Verarbeitung: Work mit lokalem Zugriff und dots verwenden weiterhin die Cloud-Koordination. Gespräche, Tool-Ergebnisse und weiterer Aufgabenkontext verbleiben nicht ausschließlich auf dem verbundenen Computer.
Residenzschutz: Wenn eine Cloud-Richtlinie
enforce_residencyaktiviert, ist Allow local computer access sowohl für Work als auch für dots nicht verfügbar. Diese Schutzmaßnahme legt weder die Workspace-Residenz fest noch deaktiviert sie allein Work Cloud oder dots. Berechtigte Workspaces können dots weiterhin aktivieren, nachdem sie die Residenzeinschränkungen der Beta bestätigt haben; der lokale Zugriff bleibt blockiert.Aufbewahrung und Datenzugriff: Keine der beiden Funktionen bietet eine strikte Null-Datenaufbewahrung. API Zero Data Retention ist eine separate API-Kontrolle. Auch „Eyes-off“-Zusagen und Kontrollen zur Missbrauchsüberwachung unterscheiden sich von einer Null-Aufbewahrung. Wenn ein Workflow erfordert, dass keine Daten aufbewahrt werden, aktivieren Sie ihn nicht für diese Funktionen.
Prüfen Sie vor dem Rollout die Aufbewahrung, Löschung und Audit-Abdeckung für die tatsächlich beteiligten Daten und Tools. Bei Work können Gespräche, gehosteter Ausführungszustand, Dateien und Daten verbundener Apps unterschiedliche Lebenszyklen haben; das Löschen eines Gesprächs entfernt nicht jede zugehörige Kopie.
Hooks und Netzwerkkompatibilität prüfen
Unterstützte Enterprise-Hooks: Wenn verwaltete Richtlinien und Remote-Hooks aktiviert sind, verwenden Work Cloud mit lokalem Zugriff und dots administrativ verwaltete Remote-MCP-Hooks. Der Cloud-Orchestrator ruft Ihren verbundenen MCP-Dienst bei unterstützten Aufgaben- und Tool-Ereignissen auf. Konfigurieren Sie
mcp_tool-Handler in der Global-requirements.toml. Work Cloud ohne lokalen Zugriff verwendet diese Hooks nicht; diese Enterprise-Hooks sind für persönliche Konten nicht verfügbar.Work Cloud und dots mit lokalem Zugriff: Befehls-/Shell-, Prompt- und Agenten-Handler; Hooks aus lokaler Konfiguration, Plugins oder lokalen Verzeichnissen; umgebungsspezifische Hooks; sowie
SessionEnd-MCP-Hooks werden bei der Cloud-Orchestrierung nicht unterstützt, auch wenn die Aufgabe Tools auf Ihrem Computer ausführt. Wenn Ihr Workflow von einem dieser Hooks abhängt, verwenden Sie weiterhin einen rein lokalen Workflow, der ihn unterstützt, bis Sie eine Alternative geprüft haben.Rein lokale Threads in Work und Codex: Wenn sowohl Orchestrierung als auch Ausführung lokal erfolgen, funktionieren bestehende unterstützte Hooks weiterhin. Administratoren können für diesen Workflow weiterhin unterstützte verwaltete Hooks in Agent Security konfigurieren.
Fehlerverhalten und Audit-Abdeckung: Testen Sie die Callback-Verbindung, erforderliche Ereignisse und das Verhalten bei Fehlern. Eine explizite unterstützte Ablehnung kann eine Aktion blockieren. Ein
PreToolUse-Callback-Fehler, eine Zeitüberschreitung oder eine fehlerhafte Antwort kann jedoch zum Fehlschlagen des Hooks führen, ohne das Tool zu blockieren. Hooks bieten weder einen vollständigen Audit-Trail der Compliance API noch decken sie jeden internen Subagentenpfad ab.Netzwerk- und App-Kontrollen: Prüfen Sie das Feld, den Bereitstellungsweg und die Ausführungsumgebung in der Konfigurationsreferenz. Von Apps oder Geräten durchgesetzte Kontrollen können auch dann gelten, wenn der Cloud-Orchestrator eine Einstellung nicht verarbeitet. Verwaltete HTTP/SOCKS-Listener-Ports und Proxy-Listener auf Nicht-Loopback-Adressen werden von der Cloud-Laufzeit nicht unterstützt; die Unterstützung von Socket-Regeln hängt vom Ausführungspfad ab. Lesen Sie Vorrang von Netzwerkrichtlinien und Laufzeitbeschränkungen und testen Sie anschließend zulässige und blockierte Aktionen sowie die erforderlichen Verbindungen.
Bei Fragen zu lokalen Dateien, Cloud-Ausführung oder dem Vorrang von Richtlinien lesen Sie die Work-FAQ für Administratoren, Lokale Sicherheit von Work und Work-Cloud-Sicherheit.
Zugriff auf lokale Computer aktivieren
Gewähren Sie den Zugriff auf lokale Computer für Work und dots separat. Verwenden Sie Workspace-Standardberechtigungen und unterstützte benutzerdefinierte Rollen, um den vorgesehenen Benutzern oder Gruppen Zugriff zu gewähren.
Prüfen Sie vor dem Rollout die oben genannten Richtlinien und Kompatibilitätsanforderungen. Es wird empfohlen, Richtlinien in Agent Security zu prüfen oder zu erstellen. Der Bestätigungsablauf erfordert jedoch nicht, dass Sie vor der Aktivierung des Zugriffs Richtlinien erstellen. Die Richtlinienmigration gewährt keinen Zugriff auf lokale Computer.
Work
Öffnen Sie als Workspace-Inhaber Workspace settings > Permissions & roles.
Aktivieren Sie Work Cloud für die vorgesehenen Benutzer. Use Codex locally on the ChatGPT desktop app ist keine Voraussetzung für diese Funktion.
Aktivieren Sie unter Work Cloud die Option Allow local computer access. Prüfen Sie den Bestätigungsdialog. Öffnen Sie anschließend Agent Security, um Richtlinien zu prüfen oder festzulegen, oder bestätigen Sie die Aktivierung des Zugriffs.
Bitten Sie die Benutzer, auf Version 26.929 oder höher der ChatGPT-Desktop-App zu aktualisieren. Das Update ist erforderlich, damit der Zugriff auf lokale Computer mit Work Cloud wirksam wird.
Lassen Sie ein Mitglied mit den vorgesehenen Berechtigungen im Eingabefeld der Desktop-App Cloud auswählen und eine neue Aufgabe starten. Setzen Sie die Aufgabe auf einem anderen unterstützten Gerät fort und prüfen Sie den Zugriff auf eine freigegebene lokale Datei oder ein Tool, während der Computer verbunden ist.
Dots
Öffnen Sie als Workspace-Inhaber Workspace settings > Permissions & roles und aktivieren Sie dots für die vorgesehenen Benutzer unter Beachtung der oben genannten Voraussetzungen.
Aktivieren Sie unter Use Dots die Option Allow local computer access. Prüfen Sie den Bestätigungsdialog. Öffnen Sie anschließend Agent Security, um Richtlinien zu prüfen oder festzulegen, oder bestätigen Sie die Aktivierung des Zugriffs.
Bitten Sie die Benutzer, auf Version 26.929 oder höher der ChatGPT-Desktop-App zu aktualisieren. Das Update ist erforderlich, damit der Zugriff auf lokale Computer wirksam wird.
Lassen Sie die Benutzer die Details ihres dots in der ChatGPT-Desktop-App öffnen und Computers auswählen. Suchen Sie Your computer (oder den Namen des Computers), wählen Sie Allow und bestätigen Sie anschließend mit Allow access.
Lassen Sie ein Mitglied mit den vorgesehenen Berechtigungen und einem verbundenen Computer eine lokale Aufgabe mit seinem dot testen.
OpenTelemetry- und Audit-Abdeckung prüfen
Unterscheiden Sie bei der Prüfung der OpenTelemetry-Abdeckung (OTel) für Work mit lokalem Zugriff und dots zwischen lokaler Ausführungstelemetrie und Cloud-Audit-Datensätzen. Ihr lokaler Executor kann weiterhin unterstützte Ausführungsereignisse exportieren. Ereignisse der Cloud-Orchestrierung erreichen Ihren bestehenden OpenTelemetry-Collector nicht.
Verwenden Sie die Compliance API für unterstützte Cloud-Datensätze. Eine Änderung des Collector-Endpunkts stellt Ereignisse der Cloud-Orchestrierung nicht wieder her. Datensätze der Compliance API ersetzen nicht jedes Ereignis des bisherigen OpenTelemetry-Streams.
Verwenden Sie für dots die Analytics API für Nutzungsdaten und die Compliance API für unterstützte Audit-Datensätze. Validieren Sie die Datensätze, die Ihr Workflow benötigt, und zusätzlich die Übermittlung an den lokalen Collector; MCP-Hooks sind kein Ersatz für Audit-Abdeckung.
Informationen zur Cloud-Audit-Abdeckung finden Sie unter Work-Cloud-Sicherheit.
Nutzung durch Endbenutzer
Sowohl bei Work als auch bei dots muss der jeweilige Computer für lokale Schritte online und verbunden sein. Die ChatGPT-Desktop-App muss ausgeführt werden und beim passenden Konto und Workspace angemeldet sein.
Work
Geeignete Aufgaben. Geeignete neue Aufgaben, die in der ChatGPT-Desktop-App mit ausgewählter Option Cloud gestartet werden, können den lokalen Executor dieses Computers verwenden, solange er verbunden und der lokale Zugriff aktiviert ist.
Anmeldung. Verwenden Sie „Mit ChatGPT anmelden“ im vorgesehenen Workspace. API keys und Codex-Zugriffstoken ermöglichen keinen Zugriff auf lokale Computer mit Work Cloud.
Computer nicht verfügbar. Wenn der Computer zu Beginn eines neuen Gesprächsschritts nicht verfügbar ist, kann eine bestehende geeignete Aufgabe in einem Cloud-Container ohne die lokalen Dateien oder Tools dieses Computers fortgesetzt werden. Der Container setzt keine Enterprise-Anforderungen aus der lokalen Ausführung durch. Eine Aufgabe kann während eines Gesprächsschritts nicht von lokaler Ausführung in die Cloud wechseln.
Zugriff deaktiviert. Wenn der Zugriff auf lokale Computer mit Work Cloud deaktiviert wird, werden laufende Gesprächsschritte unterbrochen. Benutzer können in einem bestehenden Cloud-Gespräch einen neuen Gesprächsschritt starten; dieser verwendet Work Cloud ohne Zugriff auf lokale Dateien.
Bestehende Chats und Projekte. Aufgaben, die vor der Aktivierung dieser Funktion erstellt wurden, behalten ihren ursprünglichen Modus: rein lokal oder in der Cloud ohne Zugriff auf lokale Dateien. Starten Sie nach der Aktivierung eine neue Aufgabe, um den Zugriff auf lokale Computer mit Work Cloud zu verwenden.
Local/Cloud-Einstellung. Für Unternehmen bleiben der Local/Cloud-Schalter in der App und seine Standardeinstellung bei der Einführung unverändert. Geeignete Aufgaben mit ausgewählter Option Cloud verwenden die Cloud-Koordination und für lokale Schritte den verbundenen Computer.
Dots
Einen Computer verbinden. Öffnen Sie die Details des dots in der ChatGPT-Desktop-App und wählen Sie dann Computer. Suchen Sie Ihr Computer (oder den Namen des Computers), wählen Sie Allow und bestätigen Sie anschließend mit Zugriff erlauben. Der Computer wird für unterstützte lokale Aufgaben verfügbar.
Computer offline. Die gespeicherte Zugriffsberechtigung bleibt erhalten, aber Arbeiten, die diesen Computer erfordern, können nicht fortgesetzt werden, solange er nicht verfügbar ist. Offline bedeutet nicht, dass der Zugriff widerrufen wurde.
Zugriff entfernen. Wählen Sie Zugriff widerrufen und bestätigen Sie, um die Berechtigung des dots für diesen Computer zu entfernen. Getrennt bedeutet, dass der Zugriff entfernt wurde; dieser Status unterscheidet sich von Offline.
Zugriffsänderungen durch Administratoren. Wenn ein Administrator den Zugriff auf lokale Computer für dots deaktiviert, wird eine bereits autorisierte lokale Aufgabe möglicherweise noch abgeschlossen. Gehen Sie nicht davon aus, dass das Work-Verhalten, laufende Gesprächsschritte sofort zu unterbrechen, auch für dots gilt.
Laufende Aufgaben. Eine laufende lokale Aufgabe wird nicht automatisch in die Cloud verlagert. Verbindungsänderungen können die Arbeit unterbrechen oder die Laufzeit neu laden. Der dot kann nachfolgende Arbeiten auf seinem Cloud-Computer fortsetzen. Eine lokale untergeordnete Aufgabe, die keinen Zugriff mehr hat, kann jedoch auf diesem Computer nicht fortgesetzt werden und wird nicht automatisch in die Cloud verschoben.