Auf Englisch lesen

Freigeben über


Migrieren von früheren Versionen der PK und des Servers

Empfehlungen für PlayReady Services

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.

Empfehlungen für PlayReady-Gerätehersteller

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

OEM-Upgradeplan

  1. 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).

  2. Laden Sie die PK 4.0 von Microsoft herunter.

  3. Erhalten Sie Support von Microsoft-Partnern oder direkt von Microsoft, indem Sie E-Mails an AskDRM@microsoft.com.

  4. Implementieren Sie PK 4.0, und geben Sie Ihr Produkt frei.

Migrationsnotizen für Dienste

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.

Migrieren eines PlayReady-Diensts zu Server SDK 4.0

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 Kompilieren und Bereitstellen eines aktualisierten Lizenzhandlers muss Folgendes berücksichtigen:

  • 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.

    Target Framework

  • 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.

    Referencing Microsoft.Media.Drm.RMCore

  • 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.

    Editing the Application Pool

  • 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.

Unterstützen verschiedener Server SDK-Versionen für einen Dienst

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.

Recommended Migration

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.

Hosting a Second License Service

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.

Configuring a Proxy

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> 

Unterstützen von Clients basierend auf PK 3.0 oder höher mit älteren Lizenzdiensten

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.

Security Level Hardcoded

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.

Compatibility with SL3000 Devices

Unterstützung von PlayReady 3.X und höheren Features für Dienste

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.

Detecting a PlayReady 3 client

Sobald der Handler erkannt hat, kann der Handler Richtlinien wie Secure Stop, Echtzeitlizenzablauf und MaxResDecode hinzufügen.

Unterstützen von SL2000 und SL3000 in Diensten

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:

Different Policies Based on SecurityLevel

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.

Weitere Informationen

PlayReady-Produktversionen

Testen von PlayReady-Clients mit Versionen des PlayReady Server SDK