Sektion 18: Custom OMA-URI Policies: Wenn es im Katalog fehlt

Ein vollständiges, echtes Beispiel:

./Device/Vendor/MSFT/Policy/Config/Chrome/ BrowserSignin

Diese URI adressiert im Policy-CSP die Einstellung BrowserSignin innerhalb der Area-Gruppe Chrome — im Device-Kontext. (Das Leerzeichen hier nur zur Lesbarkeit; im echten URI steht der Name ohne Unterbrechung: ./Device/Vendor/MSFT/Policy/Config/Chrome/BrowserSignin.)

Die wichtigsten CSPs im Alltag

Du wirst in der Praxis mit einer überschaubaren Menge an CSPs arbeiten. Die fünf, die du auswendig kennen solltest:

• Policy CSP (./Vendor/MSFT/Policy/Config/...) — Das Arbeitstier. Fast alle Gruppenrichtlinien-Äquivalente, die Microsoft über MDM anbietet, leben hier. Area-Gruppen sind u.a. ADMX_Ingested (für ingested ADMX), Defender, Settings, System, Update.
• BitLocker CSP (./Device/Vendor/MSFT/BitLocker) — Detaillierte BitLocker-Steuerung inklusive Remediation-Status, die im Settings Catalog oft fehlt.
• Update CSP (./Vendor/MSFT/Policy/Config/Update/...) — Windows Update for Business-Steuerung: Pausen, Ziel-Releases, Feature-Update-Deferrals.
• AppManagement CSP — Sideloading-Keys, App-Steuerung.
• ADMX-Ingested via Win32-App-Transform — kein CSP im engeren Sinne, aber der Weg, eigene ADMX-Dateien über den Policy-CSP zu importieren. Mehr dazu unter Best Practices.

Die vollständige, autoritative Referenz aller CSPs und Einstellungen liefert Microsoft in der Dokumentation "Configuration service provider reference" — dort ist jede Einstellung mit exakter URI, Datentyp und gültigen Werten dokumentiert. Behalte diesen Link bookmarked; er ist die Bibel dieser Sektion.

Datentypen: String, Integer, Boolean, Base64 und das Boolesche Format-Problem

Eine Custom Policy besteht immer aus drei Dingen: der OMA-URI, dem Datentyp und dem Wert. Intune bietet in der Dropdown-Liste diese Datentypen:

• String — Für Textwerte. Der flexibelste Typ, aber auch der gefährlichste: Ein String akzeptiert fast alles, auch syntaktisch kaputte Werte, und der Fehler zeigt sich erst clientseitig.
• Integer — Für numerische Werte. Viele CSPs verlangen Ganzzahlen (z.B. Telemetrie-Level 0-3).
• Boolean — Wahr/falsch. Achtung: In Intune wählst du hier true/false als Boolesche Ausprägung, aber viele CSPs — insbesondere der Policy CSP für Registry-basierte ADMX-Einstellungen — verlangen stattdessen die Strings <enabled/> bzw. <disabled/> (siehe Praxis-Teil).
• Base64 (Certificate .cer file) — Für Zertifikate und binäre Blob-Daten. Die Datei wird base64-kodiert übertragen.
• XML — Für strukturierte Payloads, z.B. beim CustomURI-Ansatz oder AppLocker-Regeln.

Das Boolesche Format ist die größte Stolperfalle überhaupt: Wenn die Microsoft-Dokumentation zu einer Policy-CSP-Einstellung als Wert <enabled/> angibt, dann ist das literaler Text, den du als String übertragen musst — nicht etwa ein Boolean. Das gilt für alle Einstellungen, die intern auf ADMX/Registry abgebildet sind. Einstellungen, die native MDM-Einstellungen sind (z.B. AllowTelemetry), nutzen dagegen echte Zahlen oder Booleans.

Praxis-Implementierung: Custom Policies Schritt für Schritt

Die Anatomie einer Custom Policy in Intune

Der Weg in der Konsole ist kurz: Devices → Configuration → Create → New Policy → Platform "Windows 10 and later" → Profile "Templates → Custom". Danach landest du im Konfigurations-Designer, wo du über Add beliebig viele OMA-URI-Zeilen definierst. Jede Zeile hat die Felder Name (nur für dich/intern), Description (optional), OMA-URI, Datentyp und Value. Eine Custom-Policy-Definition kann also dutzende einzelne URIs bündeln — das ist gleichzeitig Stärke und Schwäche, denn die Policy schlägt als Ganzes fehl, wenn auch nur eine URI syntaktisch invalide ist.

Beispiel 1: Telemetrie-Level setzen (Integer, Device-Kontext)

Klassischer Fall: Du willst das Diagnosedaten-Level auf "Required" (Security) setzen — der minimale Wert, der in der EU-DSGVO-Diskussion oft gefordert wird. Im Settings Catalog heißt die Einstellung "Allow Telemetry", aber hier bauen wir sie manuell:

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/System/AllowTelemetry
Datentyp:  Integer
Wert:     0

Die gültigen Werte: 0 = Security (nur Enterprise/Education), 1 = Basic, 2 = Enhanced, 3 = Full. Hinter dieser einen URI steckt die komplette Logik des Policy-CSP: Intune schickt ein <Replace>-Command an diesen Pfad, der Windows-Client schreibt den Wert in die Registry (hier konkret HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection) und meldet über <CmdID>-Status zurück.

Beispiel 2: ADMX-basierte Einstellung via Policy CSP (String, das <enabled/>-Format)

Jetzt der anspruchsvollere Fall — eine Einstellung, die intern auf einer ADMX/Registry-Policy basiert. Beispiel: Du willst die Windows-Funktion "Windows Spotlight on Lock Screen" deaktivieren, aber die zugehörige Administrative Template-Einstellung ist (hypothetisch) noch nicht im Katalog. Die CSP-Dokumentation von Experience-Area-Gruppen verlangt das String-Format:

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/Experience/ConfigureWindowsSpotlight
Datentyp:  String
Wert:     <disabled/>

Beachte exakt diese Punkte:

• Der Wert ist der Literalstring <disabled/> — inklusive der spitzen Klammern. Kein Boolean, kein einfaches false.
• Für Einstellungen mit Optionen gibt es erweiterte Formate: <enabled/><data id="SomeName" value="1"/> — die data id musst du aus der CSP-Dokumentation der jeweiligen Einstellung abschreiben, sie entspricht dem Options-Namen aus der ADMX-Datei.
• Bei Werten mit Anführungszeichen im Payload (z.B. bei Strings, die selbst XML-Fragmente enthalten) muss der Wert zusätzlich in den Kontext-Tag <Enabled/>...</Enabled/> bzw. mit CDATA-Sektionen übertragen werden — genaue Syntax steht je Einstellung in der Doku.

Beispiel 3: Windows Update für Business — Ziel-Releases-Feature

Ein Dauerbrenner: Du willst auf einem stabilen Release bleiben, während neue Feature-Updates rollen. Über den Update CSP:

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/Update/TargetReleaseVersion
Datentyp:  String
Wert:     "23H2"

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/Update/ProductVersion
Datentyp:  String
Wert:     "Windows 11"

Diese beiden URIs gehören immer zusammen — TargetReleaseVersion ohne ProductVersion ist auf Windows 11 unvollständig. Und hier siehst du eine Eigenheit: Obwohl es "Versionen" sind, ist der Datentyp String, und der Wert wird (bei dieser Einstellung) in Anführungszeichen übertragen. Die CSP-Doku sagt dir für jede Einstellung, ob Quotes nötig sind — genau lesen, nicht raten.

Beispiel 4: Chrome-Verwaltung via ingested Chrome-ADMX-Policy

Google veröffentlicht seine Chrome-ADMX-Dateien zum Ingesting. Sobald du die Chrome-ADMX einmal über eine Custom Policy (als ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/Chrome/Policy/ChromeAdmx mit Datentyp String und dem kompletten ADMX-XML als Wert) ingestiert hast, stehen dir danach alle Chrome-Policies unter ./Device/Vendor/MSFT/Policy/Config/Chrome/<PolicyName> zur Verfügung:

OMA-URI:  ./Device/Vendor/MSFT/Policy/Config/Chrome/BrowserSignin
Datentyp:  Integer
Wert:     2

2 bedeutet hier "Sign-in and force users to sign-in to use the browser". Das Prinzip ist immer dasselbe: ADMX ingestieren (einmalig), danach können die Policies einzeln per Custom URI gesetzt werden — mit denselben Werten, die auch die Chrome-ADMX-GPO definiert. Das Gleiche funktioniert für jede Third-Party-ADMX: Firefox, Zoom, Adobe, alles, was ADMX-Dateien mitliefert.

Beispiel 5: AppLocker-Regeln als XML-Payload

Der AppLocker-CSP verlangt ein komplettes Regel-XML als String-Wert. Hier siehst du, wie mächtig Custom Policies werden, wenn der Payload komplex ist:

OMA-URI:  ./Device/Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/GroupId/Policy/EnforcementMode
Datentyp:  String
Wert:     <EnforcementMode>AuditOnly</EnforcementMode>

Die GroupId ist ein frei wählbarer Bezeichner (z.B. "IntuneAppLocker"). Eine zweite URI transportiert die eigentlichen Regeln unter .../EXE/Policy mit einem vollständigen AppLockerRuleCollection-XML. Für volle AppLocker-Abdeckung brauchst du mehrere URIs (EXE, DLL, Script, MSI, AppX) — hier lohnt sich eine Custom-Policy mit sieben bis zehn Zeilen, sauber benannt, statt sieben einzelner Profile.

Zuweisung, Sync-Zyklen und was der Client daraus macht

Nach dem Erstellen weist du die Policy wie gewohnt über Entra-Gruppen zu (dynamisch oder statisch). Der Client verarbeitet Custom Policies im normalen Intune-Policy-Sync — der Standardzyklus beträgt 8 Stunden, bei Anmeldung und manchem Neustart wird zusätzlich getriggert. Mit Get-DeviceManagementConfigurationPolicy... nein — clientseitig prüfst du den Status über die SyncML-Verarbeitung: — Stopp, hier korrekt: Clientseitig läuft die Auswertung über den MDM-Agenten, und der sichtbare Status landet in Intune unter Devices → Configuration → Profile → dein Profil → Device status. Dort sieht jeder Device einen der drei Statuswerte: Success, Error oder Pending. Und genau bei "Error" beginnt der interessante Teil — dazu gleich mehr im Troubleshooting.

Für einen sofortigen Test-Sync auf einem Testgerät: Settings → Accounts → Access work or school → dein Account → Info → Sync. Oder per PowerShell als Admin:

# Sofortigen MDM-Sync triggern (lokales Gerät)
Get-ScheduledTask -TaskName "PushLaunch" | Start-ScheduledTask

Der Scheduled Task "PushLaunch" (unter \Microsoft\Windows\EnterpriseMgmt\<EnrollmentID>\) zwingt den MDM-Stack, sofort zum Server zu connecten. Das spart dir in der Testphase Stunden warten.

Werte validieren: Die Registry als Wahrheitsinstanz

Die meisten Policy-CSP-Einstellungen schreiben letztlich in die klassische Gruppenrichtlinien-Registry unter HKLM\SOFTWARE\Policies\... oder HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\.... Das macht die Verifikation clientseitig simpel. Beispiel für unsere Telemetrie-Policy:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" `
                 -Name "AllowTelemetry"

# Erwartete Ausgabe bei Wert 0:
# AllowTelemetry : 0

Wenn der Registry-Wert stimmt, ist die Policy technisch angekommen — egal, was dir irgend ein Dashboard erzählt. Umgekehrt gilt: Registry-Wert falsch oder fehlend = der Client hat die Policy nicht (korrekt) verarbeitet. Diese simple Zweiteilung trennt Server-Probleme von Client-Probleme und gehört in jedes Troubleshooting-Repertoire.

Best Practices: Custom Policies ohne Kollateralschaden

1. Custom ist ein Ausnahmewerkzeug, kein Standardwerkzeug

Die goldene Regel zuerst: Wenn eine Einstellung im Settings Catalog oder in den Administrative Templates existiert, nimm sie dort. Der Katalog bietet dir type-safety (Dropdowns statt freier Textfelder), dokumentierte Werte, Updates bei neuen Windows-Builds und Reporting. Eine Custom Policy friert deine URI ein — wenn Microsoft den CSP-Pfad ändert (das passiert, selten, aber es passiert), bekommst du das nicht mit, außer durch eigene监测 — pardon, eigenes Monitoring. Prüfe deshalb halbjährlich, ob deine Custom-URIs inzwischen im Katalog angekommen sind, und migriere dann.

2. Eine Policy pro logischem Themengebiet

Bündel mehrere URIs, die thematisch zusammengehören (alle Chrome-Policies in einem Profil, alle Update-Policies in einem anderen). Aber mische nicht: Ein Profil, das Telemetrie, BitLocker und Drittanbieter-ADMX enthält, wird bei der Fehlersuche zur Qual, weil der Error-Status sich immer nur auf die Policy als Ganzes bezieht. Kleine, thematische Profile = klare Fehlerisolation.

3. Dokumentiere jede URI im Description-Feld

Das Description-Feld jeder Custom-URI-Zeile ist dein Freund. Schreibe dort hinein: die Quelle der URI (Microsoft-Doku-Link), das Format des erwarteten Werts, das Datum der letzten Prüfung. In zwölf Monaten wirst du sonst vor <enabled/><data id="..." value="1"/> sitzen und nicht wissen, welche Option "..." mal war. Erfahrungsgemäß ist die halbe Lebensdauer einer Custom Policy damit verloren.

4. Naming-Konvention für Policies

Gib deinen Profilen ein präfixbasiertes Schema: WIN-CSP-Update-TargetRelease, WIN-CSP-Chrome-Signin. Das "CSP"-Tag im Namen markiert sofort: Hier steckt manuelle URI-Arbeit drin, Vorsicht bei Änderungen. Das hilft nicht nur dir, sondern jedem Kollegen, der nach dir den Tenant betreut.

5. Testen auf einer dedizierten Pilot-Gruppe

Custom Policies können Gerät-Verhalten verändern, das im Katalog gar nicht als "supported" gilt. Rollout-Strategie: 1 Testgerät → kleine Pilot-Gruppe (5-10 Devices) → Staged Rollout via Ring-Struktur. Mindestens 48 Stunden zwischen den Ringen, damit sichergestellt ist, dass der Policy-Sync-Zyklus (8h) mindestens einmal durchgelaufen ist, bevor du skaliertest.

6. Werte immer aus der Doku kopieren, nie konstruieren

Klingt banal, ist aber der häufigste Fehler: Admins "erraten" Werte, weil sie das Format von einer ähnlichen Einstellung ableiten. Die CSP-Doku ist für jede Einstellung eindeutig. Besonders bei Strings mit Kontext-Tag-Struktur (etwa <enabled/><data id="X" value="Y"/>) ist ein ausgelassenes Detail der Unterschied zwischen funktionierend und still fehlgeschlagen.

7. Ein vollständiges Beispielprofil als JSON (via Graph API)

Für die Automatisierer unter euch: Custom Policies lassen sich auch komplett über Microsoft Graph als deviceConfiguration erstellen. Das JSON-Schema für ein Custom-Profil:

{
  "@odata.type": "#microsoft.graph.windows10CustomConfiguration",
  "description": "Sektion 18 Demo: Telemetrie + Update Target Release",
  "displayName": "WIN-CSP-Demo-Telemetry",
  "omaSettings": [
    {
      "@odata.type": "#microsoft.graph.omaSettingInteger",
      "displayName": "AllowTelemetry auf Security",
      "omaUri": "./Device/Vendor/MSFT/Policy/Config/System/AllowTelemetry",
      "value": 0,
      "isEncrypted": false
    }
  ]
}

Damit kannst du Custom Policies versioniert im Git ablegen und per Pipeline (z.B. mit dem Graph PowerShell SDK New-MgDeviceManagementDeviceConfiguration) deployen. Wer den Intune Mastercourse bis hierher gelesen hat, ahnt: Das ist der Einstieg in Infrastructure-as-Code für Device Configuration — und passt direkt zur Automation-Philosophie dieses Kurses.

Troubleshooting: Wenn die Policy einfach nicht ankommt

Status-Interpretation im Intune-Portal

Zuerst die grobe Sortierung im Portal (Devices → Configuration → dein Profil → Device status):

• Pending — Der Client hat die Policy noch nicht abgerufen. Ursache: Sync-Zykklus noch nicht durchlaufen, oder das Device ist offline. Lösung: Sync triggern (siehe oben) oder warten.
• Error — Der Client hat die Policy erhalten, konnte sie aber nicht anwenden. Hier beginnt die eigentliche Fehlersuche.
• Success — Angewendet. Verifikation trotzdem clientseitig machen (Registry-Check), denn "Success" bedeutet nur "der MDM-Stack hat das Command quittiert", nicht automatisch "die Einstellung wirkt, wie du dachtest".

Fehlercode 2016145611 / "ErrorCode 0x87d1fde8" — Die Klassiker

Der berüchtigte 0x87d1fde8 (bzw. seine Verwandten wie 0x87d1fde8 remediation failed) bedeutet fast immer: Der Client konnte den Wert am CSP-Pfad nicht setzen. Die typischen Ursachen in Reihenfolge ihrer Häufigkeit:

• Typo im URI — ein fehlendes ./-Präfix, ein falsch geschriebener CSP-Name, ein vergessenes Segment. Prüfe die URI Zeichen für Zeichen gegen die Doku.
• Falscher Datentyp — Integer-Wert als String übertragen oder umgekehrt. Besonders tückisch: Einstellungen, die "0" als String erwarten vs. solche, die Integer verlangen.
• Ungültiger Wert — z.B. <enabled/> an eine Einstellung, die native Booleans verlangt, oder eine data id, die es in der ADMX nicht gibt.
• Falscher Kontext — Device-URI im User-Context oder umgekehrt. Manche CSPs ignorieren das still (Result: "Success", aber keine Wirkung — der schlimmste Fall!), andere melden Error.

Clientseitige Diagnose mit dem MDM-Diagnostic-Log

Windows schreibt den kompletten SyncML-Verkehr in Eventlogs und Diagnostics. Das mächtigste Werkzeug: der MDM Diagnostic Report. Auf dem betroffenen Gerät (als Admin):

# MDM-Diagnosebericht erzeugen (öffnet einen Ordner mit HTML-Report + SyncML-Logs)
$log = "$env:TEMP\MDMDiag"
New-Item -ItemType Directory -Path $log -Force | Out-Null
& "$env:windir\System32\mdmdiagnostics.exe" /out "$log\MDMReport.html" /mart /lbs /ep /msi /oma /oobe /dp /tpm /ao /diag /wpr
Invoke-Item "$log\MDMReport.html"

Im generierten Report findest du unter "OMA DM Sessions" die konkreten SyncML-Transcripte: jedes <Add> und <Replace>, das Intune geschickt hat — und, entscheidend, die Server-Antwort des CSP. Wenn dort ein <Status><CmdRef>...<Data>400</Data> steht, weißt du: Der Client hat die Policy empfangen, aber der CSP hat sie abgelehnt (Status 400 = "Bad Request" — meist Formatfehler im Wert). Der SyncML-Statuscode ist deine beste Fehlerquelle:

• 200 — OK, Command erfolgreich.
• 400 — Command vom CSP nicht verstanden. URI/Wert-Formatfehler.
• 401/403 — Command nicht erlaubt (Berechtigungs-/Kontext-Problem).
• 404 — Der adressierte Knoten existiert nicht. Fast immer ein URI-Typo oder ein CSP, der auf dieser Windows-Version nicht existiert.

Ergänzend lohnt der Blick ins Eventlog Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin:

# MDM-Eventlog nach Fehlern filtern
Get-WinEvent -LogName "Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin" `
             -MaxEvents 100 |
  Where-Object { $_.LevelDisplayName -eq "Error" } |
  Select-Object TimeCreated, Id, Message |
  Format-List

Häufige Event-IDs: ID 2253 zeigt ein fehlgeschlagenes CSP-Command mit der genauen URI an, ID 1090 markiert Errors bei der SyncML-Verarbeitung. Die Message enthält meist den exakten Pfad und den Grund — damit hast du den Fehler in 80% der Fälle in Minuten eingegrenzt.

Der Fall "Success, aber nichts passiert"

Der heimtückischste Fehlermodus: Der Status ist grün, die Registry zeigt den Wert — aber das gewünschte Verhalten bleibt aus. Dafür gibt es drei typische Erklärungen:

• Winning-Policy-Konflikt — Ein anderer Mechanismus überschreibt die Einstellung: eine GPO aus dem lokalen AD (bei Hybrid-Szenarien), eine andere Intune-Policy, ein Security Baseline-Profil. Prüfe mit gpresult /h report.html (für GPO-Konkurrenz) und in Intune unter Device → Configuration Profiles → alle angewandten Profile im Blick behalten.
• CSP schreibt nicht sofort — Manche Einstellungen wirken erst nach Neustart, Abmeldung oder Trigger eines Scheduled Tasks. Die CSP-Doku nennt für jede Einstellung den Reboot-Requirement.
• Der Wert ist syntaktisch korrekt, semantisch aber wirkungslos — z.B. Option gesetzt, aber die eigentliche Haupt-Einstellung ("Enable"-Schalter) fehlt. Gerade bei ADMX-inges-ten Einstellungen mit data id-Payloads kommt es vor, dass du die Option gesetzt hast, aber das <enabled/> auf der Haupt-URI fehlt.

Eine systematische Troubleshooting-Reihenfolge

Zum Abschluss ein Repertoire, das du für jeden Custom-Policy-Fall durchlaufen kannst:

1. Portal-Status prüfen — Success/Error/Pending?
2. Sync erzwingen — PushLaunch-Task oder manuelles Sync im Settings-Panel.

3. Registry prüfen — Ist der Wert physisch angekommen? (Trennt Server- von Client-Problemen.)
4. MDM-Diagnostic Report ziehen — SyncML-Statuscode der betroffenen URI nachschlagen.
5. Eventlog scannen — IDs 2253/1090 geben dir Pfad und Grund.
6. URI gegen Doku diffen — Zeichen für Zeichen, inkl. Kontext (Device/User) und Datentyp.
7. Minimal-Repro bauen — Gleiche URI auf einem frisch enroolten Testgerät, ohne andere Policies. Wenn sie dort funktioniert, liegt ein Konflikt vor, kein Formatfehler.

Fazit: Die letzte Verteidigungslinie der Device Configuration

Custom OMA-URI Policies sind das Swiss Army Knife der Intune-Geräteverwaltung: das Werkzeug, das dich nie von einem fehlenden Katalog-Eintrag abhängig macht. Du hast in dieser Sektion gelernt, dass Intune unter der Haube nichts anderes ist als ein OMA-DM-Server, der SyncML mit dem Client tauscht — und dass du mit Custom Policies genau dort einsteigst, wo diese Abstraktion normalerweise vor dir verborgen bleibt. Du kennst jetzt die Anatomie einer URI, die Datentyp-Fallen (das <enabled/>-Format!), die Praxis vom Telemetrie-Level über Update-Target-Releases bis zum ADMX-Ingesting für Chrome und Firefox, und du hast einen Troubleshooting-Werkzeugkasten, der mit SyncML-Statuscodes und dem MDM Diagnostic Report auch die stillsten Fehler sichtbar macht.

Der wichtigstetakeaway ist aber ein disziplinärer: Custom Policies sind ein Ausnahmewerkzeug mit voller Macht und voller Verantwortung. Sie frieren Konfiguration ein, die Microsoft sonst für dich wartet — die URI ändert sich nicht mit dem nächsten Windows-Build, aber auch nicht, wenn sich der richtige Wert ändert. Dokumentiere, testest in Ringen, migriere zurück in den Katalog, sobald eine Einstellung dort ankommt. Wer diese Balance hält, hat mit Custom OMA-URIs kein Risiko, sondern einen entscheidenden Zeitvorteil: neue Features steuern, Monate bevor der Katalog sie offiziell aufnimmt. Und genau das ist der Unterschied zwischen einem Admin, der Konfiguration konsumiert — und einem, der sie engineered.