Migration 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. Dadurch wird die beste Kompatibilität auf neuen und älteren Geräten bereitgestellt. Die neuesten Versionen des Server SDK haben auch erhebliche Leistungs- und Stabilitätsverbesserungen hinzugefügt. Beachten Sie, dass für das Upgrade auf den neuesten PlayReady Server 4.0 keine zusätzlichen Lizenz- oder Lizenzgebühren erforderlich sind .

• Da neue Geräte die Migration von PlayReady auf die Hardware (SoC) fortsetzen, werden immer mehr Geräte für einen Dienst als PlayReady 3.0 und höher und SL3000 gemeldet. Beispielsweise werden alle Windows 10-Geräte jetzt als PlayReady 3.0 und höher eingestuft. Dienste werden empfohlen, ein Upgrade auf die neueste Version des Server-SDK durchzuführen, um die Kompatibilität aufrechtzuerhalten und einige der neuen Features zu nutzen.

• Verwenden Sie die Informationen in diesem Thema als Leitfaden, um Sonderfälle wie das Verwalten von Legacy-Lizenzdiensten as-is während der Unterstützung neuer Geräte zu behandeln.

• Lizenznehmer können askdrm@microsoft.com kontaktieren, um Zugriff auf unsere Feedback-Website zu erhalten und Migrationsfragen einzureichen.

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 wurden. Dies ist die einzige Version, mit der Geräte die neuesten Funktionen nutzen können, die von top-Mediendiensten implementiert werden.

OEM Upgrade Plan

1. Wenden Sie sich an Ihre Dienste, und stellen Sie sicher, dass sie alle migrieren oder eine 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 einen Lizenzserver auf Basis von Server SDK v1.X ausführen, können sie ihren Lizenzserver migrieren oder einen neueren Lizenzserver für die neuen Clients hinzufügen, basierend auf Server SDK 2.0+ (neuste Version wird empfohlen).

2. Laden Sie die PK 4.0 von Microsoft herunter.

3. Erhalten Sie Support von Microsoft-Partnern oder direkt von Microsoft durch Senden von 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 unabhängig von der verwendeten Porting Kit-Version an alle PlayReady-Clients übermitteln. Wenn ein Client, der mit dem 3.0 oder höheren Device Porting Kit 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 wird im Windows-Protokoll eine Ausnahme aufzeichnen, die darauf hinweist, dass bei der 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 transparent sein, die auf den Dienst zugreifen.

Das Kompilieren und Bereitstellen eines aktualisierten Lizenzhandlers muss Folgendes berücksichtigen:

• Das Projekt muss Verweise auf die alten PlayReady-Bibliotheken entfernen und vor dem erneuten Kompilieren auf die neuen verweisen.

• Für die neueren Server-SDKs ist .NET 4.0 oder höher erforderlich. Beim Upgrade des Lizenzdiensthandlers von einer frühen Version wie 1.52 muss das Zielframework in den Projekteigenschaften auf 4.0 oder höher aktualisiert werden.

  

• Wenn der Legacyhandler auf andere Bibliotheken verweist, die auf eine .NET-Version unter 4.0 abzielen, können zusätzliche Migrationsschritte ausgeführt werden. Eine .NET-Bibliothek kann jedoch ohne probleme im Allgemeinen auf eine geringere Version verweisen. Es wäre sinnvoll, die Möglichkeit zu erwägen, referenzierte Bibliotheken auf die Version des Handlers neu zu kompilieren oder Bibliotheksupdates für Komponenten von Drittanbietern zu erwerben.

• Nur auf Microsoft.Media.Drm.RMCore muss innerhalb des Projekts verwiesen 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 eine .NET CLR-Version von 4.0 erforderlich. Wenn der Lizenzdienst 2.0 oder früher ausgeführt wurde, wird er wahrscheinlich in einer .NET CLR-Version unter 4.0 ausgeführt.

  

• Das neueste PlayReady Server SDK wird nur unter Windows Server 2012 und höher unterstützt. Windows Server 2008 R2 ist jedoch nicht dafür bekannt, Probleme mit dem Server SDK zu haben.

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 möchte ein Dienst jedoch möglicherweise mehrere Versionen des Server SDK ausführen. Dies kann auf die Aufrechterhaltung 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 gleichzeitig den älteren Dienst unberührt lassen. Beispielsweise kann ein Dienst über eine Reihe von Legacygeräten innerhalb ihres Ökosystems verfügen, auf denen ein mit PlayReady PK 1.2 erstellter Client ausgeführt wird. Ihre neuen Geräte werden mit 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ät für viele Dienste auf allen Geräten bereitstellen. Ein Dienst muss über Clients hinweg getestet werden, 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 älteren Gerä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) verwenden, um Lizenzen für alle diese Geräte zu bedienen. Die Anwendung kann die Logik enthalten, um die Anforderungen basierend auf der Version des zugrunde liegenden PlayReady-Clients an den richtigen Lizenzserver weiterzuleiten, oder der Dienst kann einen Dienstproxy verwenden, der die Anforderungen, die von allen diesen Geräten stammen, über eine einzelne URL an den entsprechenden Lizenzserver weiterleiten.

Dies kann in einem Proxy erfolgen, indem die Lizenzherausforderung geprüft wird. Die PK-Version wird im <CLIENTVERSION> Element angegeben.

Das Element befindet sich in der SOAP-Abfrage unter dem folgenden Element:

<Challenge><LA><CLIENTINFO><CLIENTVERSION>3.1.0.1017</CLIENTVERSION> 

Unterstützung von Clients, die auf PK 3.0 oder höher basieren, mit veralteten 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 bereits erwähnt, muss ein Dienst die Clients von 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 die Sicherheitsstufe über das Clientzertifikat in der Lizenzverwaltung als 3000 gemeldet. 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 üblich für Dienste, die eingeschränkten Inhaltszugriff für Testgeräte bereitstellen, um die Wiedergabelizenzen von einem Live-Dienst zu validieren. 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 Beispiel unten wird SecurityLevel im Clientzertifikat überprüft, 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 betrachtet.

Im nächsten Beispiel wird die Überprüfung der Sicherheitsstufe dahingehend aktualisiert, dass sie größer oder gleich 2000 ist. Dadurch wird die Kompatibilität mit SL3000-Geräten sichergestellt.

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 nutzen kann. 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, enthält er die Eigenschaft SupportedFeature.PlayReady3Features in der Sammlung. Es gibt zusätzliche nützliche Features in der Sammlung, z. B. ob der Client eine sichere Uhr oder eine Antirollbackuhr verwendet.

Nachfolgend finden Sie ein Beispiel für die Erkennung, ob es sich bei dem Gerät um einen PlayReady 3.0-Client handelt.

Sobald dies erkannt wurde, kann der Handler Richtlinien wie z. B. Sicheres Anhalten, Ablauf der Lizenz in Echtzeit und MaxResDecode hinzufügen.

Unterstützung für 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 in einer vertrauenswürdigen Ausführungsumgebung erfüllt haben, wie in den Compliance- und Robustness-Regeln 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, z. B. SL2000 melden. Neue Windows 10-Geräte werden als SL3000 angegeben, wenn das DRM in die neueren Chips integriert wurde.

Hier ist ein Beispiel für einen Dienst, der verschiedene Richtlinien bereitstellt, da die gemeldete Sicherheitsstufe von der Herausforderung des Kunden abhängt.

Ein Dienst bestimmt, wie sich Richtlinien zwischen softwarebasierten DRM-Clients und hardwarebasierten DRM-Clients unterscheiden sollten. Diese Richtlinien können von Studioanforderungen gesteuert werden. Beispielsweise kann ein Studio 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 Versionen von Richtlinien für Auflösungen können auf verschiedene Arten umgesetzt 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 auflösungen bereitstellen, die für einen softwarebasierten Client zulässig sind. 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.

Siehe auch

PlayReady-Produktversionen

So testen Sie PlayReady-Clients mit Versionen des PlayReady Server SDK