Audio Visual Design Guidelines

Content Servers & Storage

56 views November 22, 2018 November 19, 2019 aetm 0

Local Storage

Most digital signage systems, regardless of size, utilise the local storage of media players to store content and playlists ready for playback. Local storage will be used to store current, upcoming or incidental playlists (e.g. emergency messaging).

Local storage size will be defined by the playlists, inclusive of the varying content asset types and respective file sizes (e.g. plain text, pictures, videos, etc). It will also be used to cache content that is streamed or downloaded from a url.

The AETM recommend managing content centrally to avoid end users the overhead of managing manual content updates. Physical media is not recommended. Be aware that the use of removable storage presents an opportunity to override or remove content, presenting a security risk. 


Remote Network Storage

Large-scale digital signage systems commonly require a centralised repository to digitally store all content assets. A Content Management System (CMS) is used to manage assets and templates stored on the remote network storage. Common remote network storage methods:

  • On-premise server or Network Attached Storage (NAS)
  • Cloud-based storage
  • Wide Area Network (WAN) storage or Storage Area Network (SAN)

Note: Planning and deployment of digital signage remote network storage must be factored in to ICT architecture design


Content Management System

A digital signage Content Management System (CMS) facilitates the administration and management of digital signage assets including content publishing and scheduling, and in some cases signage endpoint hardware management.

The decision to use an on-premise service or a cloud-based solution are both equally valid, and every organisation’s environment is different. Regardless of approach, a CMS should always:

  • provide the functionality required by end users for the publishing and scheduling of their content
  • provide the administrative requirements, as well as access to hardware device network if remote support of endpoints is a feature set of the system
  • integrate with the core network of the organisation
  • align with ICT architectural requirements
  • align with ICT security policies regarding user authentication and administrator access
  • align with ICT governance policies regarding software and content updates
  • have a defined support model at a server, content and endpoint 

Some considerations for the deployment of an on-premise digital signage CMS include:

  • complete control over server hardware, environment and costs
  • control over security, including placement of server behind an organisation’s firewall
  • scalability of servers may attract higher cost, complexity and time, depending on on-premise hosting capabilities 
  • higher cost of initial deployment
  • generally lower cost of server ownership and storage over time
  • storage can be local if required for security posture
  • increased time required to establish the digital signage service
  • appropriate access should be considered for content and publishing, e.g. via VPN or public-facing web interface
  • internal support teams are responsible for all software, maintenance and security patching

Some considerations for cloud-based deployment of digital signage CMS include:

  • cost and time efficiency of initial digital signage service setup
  • ongoing cost should be based on only the computing and storage resources that are used, allowing a scalable solution that is suitable now and into the future
  • support, maintenance and patching of cloud-based servers can be externalised
  • endpoints require an internet connection to pull content for local caching and playback
  • access for publishing is generally via the internet rather than exclusive to a local network
  • server hardware can scale-out automatically when required to cater for additional endpoints or content
  • storage location of digital signage assets may be important to your organisation

Hybrid models combining elements of the above options are also possible, but these will always be unique to the organisation’s ICT architectural requirements and design.

Was this helpful?