Training
Lernpfad
Lösungsarchitekt: Microsoft Power Platform-Lösungen entwerfen - Training
Erfahren Sie, wie ein Lösungsarchitekt Lösungen entwirft.
Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Microsoft empfiehlt die folgenden Migrationsrichtlinien:
Stellen Sie sicher, dass ein Dienst auf die neueste Version des PlayReady SDK aktualisiert wird. Dies bietet die beste Kompatibilität über neue und ältere Geräte hinweg. Die jüngsten Versionen des Server SDK haben auch erhebliche Leistungs- und Stabilitätsverbesserungen hinzugefügt. Beachten Sie, dass keine zusätzlichen Lizenzierungs- oder Lizenzgebühren erforderlich sind , um auf den neuesten PlayReady Server 4.0 zu aktualisieren.
Da neue Geräte die Migration von PlayReady auf die Hardware (SoC) fortsetzen, werden immer mehr Geräte an einen Dienst als PlayReady 3.0 und höher und SL3000 gemeldet. Beispielsweise melden alle Windows 10 Geräte jetzt als PlayReady 3.0 und höher. Dienste werden empfohlen, auf die neueste Version des Server SDK zu aktualisieren, um Kompatibilität zu gewährleisten und einige der neuen Features zu nutzen.
Verwenden Sie die in diesem Thema bereitgestellten Informationen als Leitfaden zum Behandeln von Edgefällen, z. B. die Verwaltung von Legacylizenzdiensten während der Unterstützung neuer Geräte.
Lizenzen können sich kontaktieren askdrm@microsoft.com , um Zugriff auf unsere Feedbackwebsite zu erhalten, um Migrationsfragen zu übermitteln.
Es wird dringend empfohlen, dass OEMs ihre Geräte auf PK4.0 aktualisieren, die im Oktober 2017 veröffentlicht wurde, was die einzige Version ist, mit der Geräte die neuesten Funktionen nutzen können, die von top-Mediendiensten implementiert werden.
Vorteile | Nachteile - Aufmerksamkeitspunkte |
---|---|
Kann SL3000 unterstützen | Nicht kompatibel mit Server SDK 1.X |
Kann neueste Funktionen wie SecureStop, SecureDelete, MaxResDecode usw. implementieren | |
Bessere Codebasis | |
Sicherstellen, dass neue Lizenzrichtlinien wie von Inhaltsbesitzern angefordert werden können |
Wenden Sie sich an Ihre Dienste, und stellen Sie sicher, dass sie alle migrieren oder ein Server SDK 2.0+ version hinzufügen.
Überprüfen Sie die Server-SDK-Version.
Wiederholen Sie überlegungen für den Dienst: keine zusätzlichen Lizenzierungsanforderungen von Microsoft und keine zusätzlichen Gebühren.
Wenn sie einen server SDK v2.0+ basierenden Lizenzdienst ausführen, sind sie wahrscheinlich kompatibel. Die Dienst-URLs und Szenarien im nächsten Abschnitt können bei Kompatibilitätstests helfen.
Wenn sie ein Server SDK v1 ausführen. X-basierte Lizenzserver können ihren Lizenzserver migrieren oder einen neueren Lizenzserver für die neuen Clients hinzufügen – basierend auf server SDK 2.0+ (neueste Version wird empfohlen).
Laden Sie die PK 4.0 von Microsoft herunter.
Erhalten Sie Support von Microsoft-Partnern oder direkt von Microsoft, indem Sie E-Mails an AskDRM@microsoft.com.
Implementieren Sie PK 4.0, und geben Sie Ihr Produkt frei.
Stellen Sie für optimale Gerätekompatibilität sicher, dass der Lizenzserver die neueste Version des Server SDK ausführt. Das neueste Server SDK kann lizenzen für alle PlayReady-Clients bereitstellen, unabhängig von der verwendeten Porting Kit-Version. Wenn ein Client, der mit dem 3.0 oder höher entwickelt wurde, versucht, eine Lizenz von einem Lizenzdienst mit PlayReady SDK 1.x zu erhalten, gibt der Lizenzdienst einen generischen dienstspezifischen SOAP-Fehler zurück. Der Server protokolliert eine Ausnahme beim Windows Protokoll, dass die Herausforderung die Clientzertifikatkette fehlte.
Ein Dienstupgrade umfasst in der Regel keine Codeänderungen, sondern nur eine Neukompilierung und Bereitstellung der aktualisierten Bibliotheken. In einigen Fällen kann es geringfügige Codeänderungen aufgrund veralteter APIs geben. Die Neukompilierung und Bereitstellung der Lizenzhandlerbibliothek sollte für Geräte, die auf den Dienst zugreifen, transparent sein.
Das Projekt muss Verweise auf die alten PlayReady-Bibliotheken entfernen und vor der Neukompilierung auf die neuen verweisen.
Die neueren Server-SDKs erfordern .NET 4.0 oder höher. Beim Upgrade des Lizenzdiensthandlers von einer frühen Version wie 1.52 muss das Zielframework in den Projekteigenschaften auf die von 4.0 oder höher aktualisiert werden.
Wenn der Legacyhandler auf andere Bibliotheken verweist, die auf eine .NET-Version kleiner als 4.0 ausgerichtet sind, können zusätzliche Migrationsschritte auftreten. Eine .NET-Bibliothek kann jedoch auf eine geringere Version verweisen, ohne dass probleme im Allgemeinen auftreten. Es lohnt sich, die Möglichkeit zu untersuchen, auf bibliotheken verwiesene Bibliotheken auf die Version des Handlers zu kompilieren oder Bibliotheksupdates für Komponenten von Drittanbietern zu erwerben.
Nur Microsoft.Media.Drm.RMCore muss innerhalb des Projekts referenziert werden. Bei der Bereitstellung einer Lösung müssen die anderen DLLs im Bin-Verzeichnis der Website bereitgestellt werden. Sie müssen nicht innerhalb des Projekts referenziert werden, wie es bei früheren SDKs der Fall war.
Für den vom Lizenzdienst verwendeten Anwendungspool ist mindestens eine .NET CLR-Version von 4.0 erforderlich. Wenn der Lizenzdienst 2.0 oder früher ausgeführt wurde, ist es wahrscheinlich, dass er in einer .NET CLR-Version unter 4.0 ausgeführt wird.
Das neueste PlayReady Server SDK wird nur unter Windows Server 2012 und höher unterstützt. Windows Server 2008 R2 ist jedoch nicht bekannt, dass probleme mit dem Server SDK auftreten.
Microsoft empfiehlt, bald nach der Veröffentlichung zur neuesten Version des SDK zu migrieren. In einigen Fällen kann ein Dienst jedoch mehrere Versionen des Server SDK ausführen. Dies kann auf die Verwaltung von Legacy- und Archivdiensten und Endpunkten zurückzuführen sein, die nicht einfach aktualisiert werden. In diesem Fall kann ein Dienst neue Clients auf einen aktualisierten Lizenzdienst verweisen und den älteren Dienst unberührt lassen. Beispielsweise kann ein Dienst eine Reihe von Legacygeräten innerhalb ihres Ökosystems haben, die einen Client ausführen, der mit PlayReady PK 1.2 erstellt wurde. Ihre neuen Geräte werden mithilfe der PlayReady PK 4.0 entwickelt. Der neue Client muss auf einen Lizenzdienst verweisen, der mit Server SDK 2.0 oder höher erstellt wurde. Wenn sowohl die Legacy- als auch die neuen Geräte dieselbe Anwendung (z. B. eine HTML-basierte App-Plattform) verwenden, muss der Anwendung Logik hinzugefügt werden, um die Version des Clients zu erkennen. Die Clientanwendung kann dann Lizenzanforderungen an einen neueren Lizenzdienst weiterleiten.
Die empfohlene Migration besteht darin, den Lizenzdienst auf die neueste Version des Server SDK zu aktualisieren. Dies kann kompatibilitätsübergreifend auf allen Geräten für viele Dienste bieten. Ein Dienst muss alle Clients testen, um die Kompatibilität zu überprüfen.
Wenn ein Dienst keine Änderungen an einer älteren Client- und Dienstkonfiguration vornehmen möchte, empfiehlt es sich, einen zweiten Lizenzdienst zu hosten, der auf die neueste Version des SDK aktualisiert wurde und von modernen Clients verwendet wird.
Wenn ein Dienst eine einzelne Clientanwendung auf beiden Legacygeräten (PlayReady 1.X) und neueren Geräten (PlayReady 3.0 oder höher) verwendet, muss er zwei PlayReady-Lizenzserver (PlayReady 1.X und PlayReady 3.0 oder höher) betreiben, um Lizenzen für alle diese Geräte zu bedienen. Die Anwendung kann die Logik enthalten, um die Anforderungen an den richtigen Lizenzserver basierend auf der Version des zugrunde liegenden PlayReady-Clients weiterzuleiten, oder der Dienst kann einen Dienstproxy verwenden, der die Anforderungen leitet, die von allen diesen Geräten auf einer einzelnen URL an den entsprechenden Lizenzserver stammen.
Dies kann in einem Proxy erfolgen, indem die Lizenzabfrage überprüft wird. Die PK-Version wird im Element angegeben.
Das Element befindet sich in der SOAP-Herausforderung unter dem folgenden Element:
<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION>
Ein Clientgerät, das mit dem PlayReady Device Porting Kit 3.0 oder höher entwickelt wurde, funktioniert wahrscheinlich mit vorhandenen Diensten, die mit dem Server SDK 2.0 oder höher entwickelt wurden. Wie oben erwähnt, muss ein Dienst PK 3.0 oder höher testen, um die Kompatibilität zu überprüfen.
Wenn das Gerät über ein SL3000-Zertifikat verfügt, wird der SecurityLevel über das Clientzertifikat im Lizenzhandler als 3000 angezeigt. Dies kann möglicherweise Probleme mit einigen Lizenzhandlern verursachen, wenn sie nach einem bestimmten SecurityLevel-Wert suchen, um zwischen Produktions- und Testgeräten zu unterscheiden.
Die Unterscheidung zwischen SecurityLevels ist für Dienste üblich, die eingeschränkten Inhaltszugriff für Testgeräte bieten, um Wiedergabelizenzen von einem Livedienst zu überprüfen. Nur Geräte, die als SecurityLevel 2000 gemeldet wurden, hätten Wiedergabelizenzen für kommerzielle Inhalte bereitgestellt. Der Dienst würde eine dienstspezifische Ausnahme auslösen, die zu einem SOAP-Fehler auf dem Client führen würde.
Im folgenden Beispiel wird das SecurityLevel im Clientzertifikat eingecheckt, um sicherzustellen, dass es sich um ein Produktionsgerät handelt. Da es auf 2000 hartcodiert wurde, werden Geräte mit der Sicherheitsstufe 3000 nicht als Produktionsgeräte angesehen.
In diesem nächsten Beispiel wird die Überprüfung auf Sicherheitsstufe aktualisiert, um festzustellen, ob sie größer oder gleich 2000 ist. Dadurch wird die Kompatibilität mit SL3000-Geräten sichergestellt.
Neben der neuen Hardware-DRM-Sicherheitsstufe haben PlayReady 3.0 und höhere Versionen auch eine Vielzahl neuer Features eingeführt. Um diese neuen Features nutzen zu können, muss der Dienst zuerst ermitteln, ob der Client PlayReady 3.0 und höhere Features besitzt. Die Clientzertifikatklasse unterstützt jetzt eine GetSupportedFeatures-Methode, die eine Sammlung von Features zurückgibt, um die Logik der Definition von Richtlinien innerhalb des Handlers zu unterstützen. Wenn der Client mit dem 3.0 Device Porting Kit entwickelt wurde, verfügt er über die SupportedFeature.PlayReady3Features-Eigenschaft in der Auflistung. Es gibt zusätzliche nützliche Features in der Auflistung, z. B. ob der Client eine sichere Uhr oder eine Antirollbackuhr verwendet.
Hier sehen Sie ein Beispiel zum Ermitteln, ob es sich bei dem Gerät um einen PlayReady 3.0-Client handelt.
Sobald der Handler erkannt hat, kann der Handler Richtlinien wie Secure Stop, Echtzeitlizenzablauf und MaxResDecode hinzufügen.
PlayReady hat eine neue Sicherheitsstufe SL3000 eingeführt, die von Geräten gemeldet wird, die die PlayReady-Hardwaresicherheitsstufe für die Ausführung innerhalb einer vertrauenswürdigen Ausführungsumgebung erfüllt haben, wie in den Compliance- und Robustnessregeln definiert. Es wird üblich sein, dass Dienste einige Clients als SL2000 und andere als SL3000 melden. In Windows können ältere Geräte, die auf Windows 10 aktualisiert wurden, beispielsweise als SL2000 melden. Neue Windows 10 Geräte werden als SL3000 melden, wo das DRM in die neueren Chips integriert wurde.
Hier ist ein Beispiel für einen Dienst, der verschiedene Richtlinien basierend auf der gemeldeten Sicherheitsstufe von der Herausforderung des Clients bereitstellt:
Ein Dienst bestimmt, wie Sich Richtlinien zwischen softwarebasierten DRM-Clients und hardwarebasierten DRM-Clients unterscheiden sollten. Diese Richtlinien können von Studioanforderungen gesteuert werden. Ein Studio kann beispielsweise in Zukunft erfordern, dass Ultra-HD- oder 4K-Inhalte auf Geräte beschränkt werden, die hardwarebasierte PlayReady DRM unterstützen.
PlayReady 3.0 und höhere Richtlinien zu Auflösungen können auf verschiedene Arten erreicht werden. Eine Möglichkeit besteht darin, die MaxResDecode-Richtlinie von SL2000-Lizenzen auf die zulässigen Grenzwerte festzulegen, die vom Inhaltsbesitzer bereitgestellt werden. Die SL3000-Geräte würden diese Richtlinieneinschränkung nicht erhalten. Eine weitere Option, die für adaptive Streamingtechnologien gilt, besteht darin, beim Schutz der verschiedenen Auflösungen eine andere KeyID zu verwenden. Bei der Erkennung der Sicherheitsstufe kann ein Dienst dann nur Lizenzen für die für einen softwarebasierten Client zulässigen Auflösungen bereitstellen. Ein Client, der eine Sicherheitsstufe von SL3000 meldet, würde Wiedergabelizenzen für alle Auflösungen erhalten. PlayReady hat einen neuen DRM-Header (v4.2.0.0 und höher) eingeführt, um dieses letztere Szenario zu unterstützen, indem mehrere KeyIDs im Schema aktiviert werden.
Testen von PlayReady-Clients mit Versionen des PlayReady Server SDK
Training
Lernpfad
Lösungsarchitekt: Microsoft Power Platform-Lösungen entwerfen - Training
Erfahren Sie, wie ein Lösungsarchitekt Lösungen entwirft.
Dokumentation
So ermitteln Sie, welche Features ein Client unterstützt - PlayReady
In diesem Abschnitt wird beschrieben, wie eine Serveranwendung bestimmen kann, ob ein Client ein bestimmtes Feature unterstützt oder nicht.
In einer Lizenzkette enthält die Blattlizenz den Inhaltsschlüssel, und die Stammlizenz ist an den Computer oder das Gerät gebunden.
PlayReady und andere Schutztechnologien - PlayReady
PlayReady-Systeme können mit anderen Inhaltsschutzsystemen interoperieren.