Jede Grenze hier ist absichtlich. Sie zu kennen, ermöglicht es Ihnen, "so funktioniert es" von "etwas ist kaputt" zu unterscheiden — was normalerweise der Unterschied zwischen einer Richtlinienänderung und einem Supportticket ist.

Überblick

Vier Einschränkungen bestimmen, wie Sie alles andere konfigurieren.

• Scoping lebt in Prosa, nicht in Umschaltern. Es gibt keinen Umschalter pro Problemtyp für ONE: es ist für das Unternehmen ein oder aus. Welche Probleme es unbeachtet lässt, ist etwas, das Sie im Abschnitt "Scope" Ihrer Richtlinie namentlich festlegen.
• Das Unveröffentlichen ist kein Notstopp. Es verhindert, dass neue Tickets zugewiesen werden, aber Tickets, die bereits bei ONE sind, bleiben bei ONE — sie lesen einfach das fehlende Mandat und stoppen mit einer Notiz. Wenn Sie Ihr Team heute darauf benötigen, weisen Sie sie manuell neu zu.
• Tickets folgen Problemen eins zu eins. Fünf Probleme auf einem Gerät bedeuten fünf Tickets. Das ist das Design, keine Duplikation.
• Richtlinien subtrahieren, niemals addieren. Ein Satz, der etwas gewährt, das das Produkt verbietet, hat überhaupt keine Wirkung.

Wie eine Reparatur erneut angewendet wird

ONE erfindet keine Reparatur. Es wiederholt, was die Kontrolle ursprünglich getan hat:

Das deckt die Mehrheit der Compliance-Probleme ab. Was es vertrauenswürdig macht, ist der Schritt danach: es liest das Gerät erneut. Ein Push, der erfolgreich gesendet wurde, beweist nichts für sich allein.

Die sechs Gründe, warum ein Ticket Sie trotzdem erreicht

Wenn ein Ticket zurückkommt, ist es fast immer einer dieser Gründe — und die Notiz nennt, welcher:

• Das Gerät ist offline, sodass nichts gepusht oder verifiziert werden kann
• Das Gerät ist in einem anderen MDM eingeschrieben, wo wir beobachten, aber nicht durchsetzen
• Die OS-Version kann für diese spezielle Kontrolle nicht verwaltet werden
• Die Reparatur benötigt einen Kauf, eine Lizenz oder ein Credential, das wir nicht haben
• Der EDR wurde nie bereitgestellt, sodass es nichts zu reparieren gibt
• Das Gerät benötigt eine erneute Einschreibung, was Ihre Entscheidung ist

Attribution

Alles ist nachvollziehbar. Geräteaktionen landen in den Audit-Protokollen wie jede andere Aktion. Eine Richtlinienänderung, die mit Ihrer Genehmigung vorgenommen wurde, wird als ONE's Änderung aufgezeichnet, und die Notiz nennt den Administrator, der sie genehmigt hat.

Demo-Unternehmen

Ein Demo-Unternehmen führt den echten Ablauf mit gefälschten Gerätedaten durch, und der Assistent ist live — das Kommentieren eines Demo-Compliance-Tickets startet einen echten Ablauf. Änderungen an den Compliance-Einstellungen und an der Richtlinie sind dort blockiert.

Fehlerbehebung und FAQ

Fehlerbehebung

1. Sie möchten, dass es Verschlüsselung funktioniert, aber keine OS-Updates. 
   Schreiben Sie das in den Scope. Es gibt keinen Umschalter dafür.
    
2. Sie haben unveröffentlicht und es ist immer noch Tickets zugewiesen. 
   Funktioniert wie vorgesehen — es hört auf zu handeln, bleibt aber zugewiesen. Weisen Sie sie neu zu.
    
3. Ein Ticket sagt, dass es nichts zu wiederholen gibt. 
   Diese Kontrolle hat keinen pro-Gerät-Mechanismus zur erneuten Anwendung. Es ist eine Produktgrenze, und die Reparatur benötigt eine Person.
    
4. Ein Satz in der Richtlinie bewirkt nichts. 
   Es versucht, die Berechtigungen zu erweitern. Richtlinien schränken nur ein.

FAQ

1. Können wir es nur für einen bestimmten Problembereich aktivieren?
   Nicht mit einer Einstellung. Nennen Sie Ihre Ausnahmen stattdessen im Abschnitt "Scope".
    
2. Wie entscheidet es, was es versuchen soll?
   Es spiegelt den eigenen Mechanismus der Kontrolle wider und bestätigt dann durch erneutes Lesen des Geräts.
    
3. Ist alles prüfbar?
   Ja — Geräteaktionen in den Audit-Protokollen und Richtlinienänderungen, die den genehmigenden Administrator benennen.