Tech Mahindra Ltd., a provider of business consulting for digital transformation and reengineering solutions, today announced a new digital platform that will be distributed ledger blockchain technology to enhance digital rights management for the entertainment industry.
The solution, named “Blockchain Based Contracts and Rights Management System,” or bCRMS, is aimed at helping production houses and content creators transform their rights management systems to streamline and secure the process of rights and royalty tracking and protect intellectual property.
The new bCRMS will make use of IBM Corp.’s blockchain-based Hyperledger Fabric protocol, which will provide the infrastructure to provide content hashing and forensic watermarking to allow tracking and tracing content. As a result, the platform can be used within other industries that require intellectual property and secured digital content management such as trade, finance and healthcare.
“Fragmentation in the media and entertainment landscape has had a profound impact on media consumption,” said Rajesh Dhuddu, blockchain and cybersecurity practice leader of Tech Mahindra. “Both media production houses and ‘over-the-top’ players are creating intriguing content to improve customer stickiness and gain market share. This has led to an exponential increase in fraud with revenue lost due to online piracy estimated to approximately $50 billion by 2022.”
An over-the-top media service is one that offers streaming media directly to viewers via the internet. The OTT model bypasses cable, broadcast and television platforms, which are traditionally the mediators for most content delivered to viewers. This new model is driven by a greater number of potential viewers watching on computers, mobile devices and users of smart TVs with apps that access internet content.
By building on the IBM Blockchain, the platform will make it possible to restrict unauthorized access and redistribution of digital content, mitigate content piracy and manage royalty payments. It’s also designed to be scalable and empower artists, fulfillment partners and distributors using a clear, automated system for accessing and managing payments.
“As part of our TechMNxt charter, bCRMS is developed to usher in the next generation of digital rights management systems for the media and entertainment industry,” said Dhuddu. The idea is to “orchestrate the entire media content life cycle workflows across pre-production, post-production and distribution phases to enhance revenues, preempt contracts or rights infringement and focus on redefining end customer’s content consumption experience.”
The bCRMS will act as a replacement for the entire digital rights management workflow experience for media businesses by using the blockchain to record and track digital rights, smart contracts to resolve royalties automatically, provide distribution channel information and allow for a trustworthy historical record of media rights.
As of April this year, Tech Mahindra also joined IBM’s public cloud ecosystem, which will allow the company to help clients transform their operations to employ cloud computing and hybrid strategies that use blockchain technology to foster trust and transparency across industries.
The entertainment industry and royalty management systems couple well with blockchain technology’s distributed digital ledgers because they can be used to record and track ownership of digitized assets automatically. For example, European music marketplace ANote Music will launch its own royalty investment platform on July 28, Fenix uses blockchain technology to connect fans and artists and Raiinmaker’s blockchain platform rolled out in beta to encourage fans and influencers.
“Digital rights management is a pressing problem impacting artists, content creators and advertisers worldwide, potentially costing the industry billions every year,” said Alistair Rennie, general manager at IBM Blockchain. “Tech Mahindra’s innovation using IBM Blockchain helps address this challenge with a new approach that offers the digital media market the ability to track the quality and authenticity of content as well as track downloads and usage of content in a clear and flexible manner.”
Tech Mahindra is rolling out its platform on IBM’s Hyperledger Fabric starting today and is now available for customers that want to develop holistic applications and build out use cases in their respective industries.
Since you’re here …
Show your support for our mission with our one-click subscription to our YouTube channel (below). The more subscribers we have, the more YouTube will suggest relevant enterprise and emerging technology content to you. Thanks!
Support our mission: >>>>>> SUBSCRIBE NOW >>>>>> to our YouTube channel.
… We’d also like to tell you about our mission and how you can help us fulfill it. SiliconANGLE Media Inc.’s business model is based on the intrinsic value of the content, not advertising. Unlike many online publications, we don’t have a paywall or run banner advertising, because we want to keep our journalism open, without influence or the need to chase traffic.The journalism, reporting and commentary on SiliconANGLE — along with live, unscripted video from our Silicon Valley studio and globe-trotting video teams at theCUBE — take a lot of hard work, time and money. Keeping the quality high requires the support of sponsors who are aligned with our vision of ad-free journalism content.
Miners, making up ~68% hash-rate, have confirmed full support for the ETC #Phoenix network upgrade, expected on ETC mainnet at block 10_500_839, around June 3, 2020.#EthereumClassic Miners Confirm Support for Phoenix Hard-Fork https://t.co/gLUuuwV2GR via @StevanLohja@etclabs
— Ethereum Classic (@eth_classic) May 4, 2020
We are having a challenge creating macOS exclusions in the Whitelist Policy. All of the online references for exclusions state using “/” in exclusions for mac, however when creating exclusions in this manner we are getting the following error:
Has anyone seen this before and is there a solution for it?
Thanks in advance,
The following environments assume that XenDesktop 5.x is installed on all DDCs and VDAs. This article is based on the registry based Controller Discovery – this is the recommended method for multiple forest registration.
The NetBIOS and Fully Quality Domain Name (FQDN) can be different. For example, the NetBIOS name could be BOB but the FQDN could be parent1.local or the NetBIOS name and FQDN can be the same:
Example: NetBIOS name is parent and the FQDN would be parent.local.
Note: Dots in NetBIOS names are not recommend.
Appropriate user access permissions are given for successful machine creation. In a cross-forest setup, use Delegation Control Wizard to keep permissions to minimum use. Permission must be given for the DDC Administrator to create machines in a different forest in a specific Organizational Unit (OU). The following minimum permission can be given for successful machine creation:
Open Active Directory Users and Computers Microsoft Management Console (MMC).
Right-click your OU and select Delegate Control.
On the first screen, click Next.
In the Users & Groups screen, click Add and pick a user or group you want to delegate rights to and click Next.
The best practice is to assign a group rather than a single user, as it is easier to manage and audit.
In the Tasks to Delegate screen, select Create a custom task to delegate and click Next.
In the Active Directory Object Type screen, select Only the following objects in folder and select Computer objects.
- Select Create selected objects in this folder and click Next.
In the Permissions screen, select General and then select Read and Write.
Click Finish to complete the delegation control.
Different types of Active Directory Setups
Simple Single Domain Deployment
The following diagram illustrates a XenDesktop deployment in a single Active Directory domain, where the DDCs, VDAs, and the users are all in the same domain.
In this Single domain setup, all relevant components and objects are based on one single domain. Registration of VDAs with the DDC should be successful and no additional configuration, that is, the registry key changes is required.
Check Event Viewer for errors on both the DDC and the VDA.
Ensure that the firewall is open for port 80 between the VDA and the DDC.
Check that the FQDN of the DDC is correct in the registry setting of the VDA machine. On the VDA, check the following Reg Key:
Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.
HKEY_LOCAL_MACHINESOFTWARECitrixVirtualDesktopAgent and confirm the parameter ListOfDDCs had the correct FQDN.
If using 64-bit Virtual Machine, the VDA Reg Key is HKEY_LOCAL_MACHINESOFTWAREWow6432NodeCitrixVirtualDesktopAgentListOfDDCs
Ensure that the DNS settings are correct on VDA and DDC, and both the computers can resolve each other by DNS name and reverse lookups. Use the XDPing tool, downloadable from the Knowledge Center article CTX123278 – XDPing Tool to further troubleshoot.
Check that the Time is in sync between the VDA and DDC are correct.
For further troubleshooting, see Troubleshooting Virtual Desktop AgentRegistration with Controllers in XenDesktop.
Single Forest with Multiple Domains or Single Forest with Multiple Domains with shortcut trusts
The following two diagrams illustrate a XenDesktop deployment in a single forest with multiple domains and a Single Forest with multiple domains with shortcut trusts – where the DDC, VDA, and Users are all based in different domains.
The following is the illustration for Multiple Domains:
The following is an illustration for Multiple Domains with short cut trusts:
Multiple Domains: DDC, Users, and VDA are based in various domains, by default, a bidirectional transitive trust relationship exists between all domains in a forest.
Multiple Domains with short cut trusts: DDC, Users, and VDA are based in various domains but at two-way shortcut, trust has been manually created between the DDC domain and the VDA domain. Typically, shortcut trusts are used in a complex forest where it can take time to traverse between all domains for authentication. By adding a shortcut trusts, it shortens the trust path to improve the speed of user authentication.
For successful registration of the VDA with the DDC, the following should be configured correctly. DNS Forward/Reverse Lookup Zones are in place and configured on the relevant DNS servers. For further troubleshooting of VDAs not registering, see Following is a list to check if VDA is unable to register with the DDC: mentioned in the Simple Single Deployment section.
Note: For Forest trusts, both Forests must be in Win2003 Forest Functional Level.
For successful VDA registration with the DDC, the following must be configured correctly:
DNS, for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional Forwarders, Forward /Reverse lookup zones and Stub zones are all acceptable for name lookup/resolution. As an example, in the preceding illustration, on the DNS server for Parent.local, a Secondary Forward Lookup Zone and a Reverse Lookup zone for Parent2.local has been added and similarly the opposite has been done on the Parent2.local. This means that the DDC should now be able to resolve the VDA by name and IP and the VDA resolves the DDC by name and IP address.
See Managing a Forward Lookup Zone for information on managing Lookup Zones.
On the Desktop Delivery Controller, enable the following registry value on the DDC. This enables support for VDAs, which are located in separate forests: HKEY_LOCAL_MACHINESoftwareCitrixDesktopServerSupportMultipleForest (REG_DWORD)
To enable VDAs located in separate forests; this value must be present and set to 1.
After changing the SupportMultipleForest value, you must restart the Citrix Broker Service for the changes to have an effect.
On the Virtual Desktop Agent, enable the following registry value on the VDA to enable support for DDCs located in a separate forest.
For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)
For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentSupportMultipleForest (REG_DWORD)
To enable support for DDCs located in a separate forest; this value must be present and set to 1.
Note: The next step is only required if External Trusts are only being used.
- If the Active Directory FQDN does not match the DNS FQDN or if the domain where the DDC resides has a different NetBIOS name to that of the Active Directory FQDN, you must add the following registry key on the Virtual Desktop Agent machine.
- For a 32-bit VDA: HKEY_LOCAL_MACHINESoftwareCitrixVirtualDesktopAgentListOfSIDs
- For a 64-bit VDA: HKEY_LOCAL_MACHINESoftwareWow6432NodeCitrixVirtualDesktopAgentListOfSIDs
The ListOfSIDs registry key contains the DOMAIN SID of the DDC. By using this key, DNS lookups are using the true DNS name of the DDC.
To obtain the correct domain SID of the DDC, the domain SID can be found in the results of the PowerShell cmdlet Get-BrokerController from an elevated PowerShell prompt on the delivery controller.
Note: You must restart the Citrix Desktop Service for the changes to have an effect.
Multiple Forests with One-Way Selective trusts
The following diagram illustrates XenDesktop deployment in a Multi-Forest Deployment using One-way Selective Trusts. The DDC is in a different Active Directory forest and the end users and existing VDAs (created either manually or through an alternative method) are in a separate Active Directory forest. In a one-way selective trust, automatic creation of Virtual Machines through DDC will fail, because of authentication issues.
For this example, the NetBIOS and FQDN are different in each Forest and domain.
Note: For One-Way Selective trusts, both Forests must be in Win2003 Forest Functional Level or above.
Configure the following for successful registration of the VDA with the DDC:
DNS for name and reverse lookups. Depending on the approach taken, the use of DNS Forwarders and Conditional forwarders, Forward/Reverse lookup zones, and Stub zones are all acceptable for name lookup/resolution.
Create the Selective trust on the relevant Domain Controllers.
Follow steps provided in the Multiple Forests with trusts (External trusts – NTLM or Forest trusts Kerberos) section.
The VDAs must be granted authentication access to the DDC. This is done through Active Directory Computer and Users snap-in.
Note: VDAs can be added to a group to make management easier (granting rights). This is recommended.
a) In Active Directory Computers and Users, browse to the location of the DDCs.
b) Right-click DDC and click Properties.
c) Click the Security tab.
d) Click Add and click Locations to change the domain to where the VDAs reside.
e) Click on Advanced, and click on Object Types. Choose ‘Computers’
f) Select all the relevant VDA or Group (recommended) and click OK.
g) Select the VDA’s or Group and give the rights – Read and Allowed to authenticate, as displayed in the following screen shot:
On the DDC, select an Existing Catalog and create a relevant Assignment. When done, the Virtual Machines should show in a Ready State, as displayed in the following screen shot:
For further troubleshooting of VDA not registering, see Following is a list to check if VDA is unable to register with the DDC section.