How To Do Remote Deployment Successfully
This article is a primer on how to use the remote deployment feature of Intuiface, the hands-free (and clothes-free) alternative to manually downloading and running experiences on devices anywhere in the world.
The "remote deployment" feature of Intuiface is the lifeblood of users with distributed Player environments. It's the hands-free alternative to manually initiating experience download and execution on a per-device basis. It's also - technically - a clothes-free alternative as remote deployment can be initiated from any Web browser, even browsers located in the privacy of your own home.
This article is a primer on how to use the remote deployment feature of Intuiface, a capability exclusive to those in possession of an Enterprise-level account.
Remote deployment has been a core component of digital signage ever since the Internet could connect Points A and B. The ability to push content to remote locations, on an optional schedule, enabled enterprises to change what was on the screen, propelling their digital communication beyond electricity-powered replacements of posters and wall art.
Intuiface users are entitled to the same level of power and flexibility. Happily, it's easy to do too. Let's see how.
Ah! You just wanted to dive into the software. That's a mistake. Planning is an indispensable first step because if it's done right, there are no surprises and no missed opportunities. Especially if you're new to the discipline, don't get cocky and think you can figure things out on the fly. Sometimes you just can't put the car in reverse, committing yourself to a less-than-ideal course of action.
So what should you be planning?
Licensing Requirements: Do you have an Enterprise-level account? How many devices will be running Player? Will you need all licenses at once, or is this a phased project and license needs will increase over time? If it’s a long project, is it in your interest to purchase discounted multi-year licenses or go annually? Conversely, if it's a short project, are you better off renewing monthly?
Networking Requirements: Will Internet access be at least intermittently available on all Player devices? (It better be or you won’t be using remote deployment or analytics.) Are there firewall issues that need to be addressed? Thinking about the aforementioned licensing requirements, will the devices be offline longer than a monthly/annual subscription, arguing for a proactive purchase of longer-term licenses? Is it a metered connection - i.e. are you paying for data transfer - influencing how often you'll make changes.
Administrative Requirements: If you're an agency or integrator, will you be using secondary accounts to manage Players? Who on your team will have the right to initiate a deployment? To decide a deployment is warranted? What do you need to capture in an audit trail? Should anyone be notified of pending deployments?
Procedural Requirements: What are the criteria for determining when a deployment is warranted? What are the appropriate schedules? Should deployments always be manually initiated as needed, or would a repeating schedule of automatically initiated deployments be preferable? Who will install Player at each remote site? When should Player software be updated?
Maybe it seems a bit intimidating but ignorance will be painful, not blissful. You need to know the answers and - good news - it's very likely your answers will apply to all projects rather than differing from one to the next. So put in the work, reach consensus, then get down to implementation.
It should come as no surprise that you need to install Player on a device in order to deploy experiences to that same device. As of today, Player installation is manual activity (with one exception for Windows PCs), so you'll need someone onsite carrying this out.
License activation procedures can vary a bit by platform, but fundamentally you have three choices:
- Log into Player for automatic license retrieval
- Enter a unique license key for each Player
- Use a credential key to initiative automatic license retrieval
Ultimately, each Player will have a unique license key. This fact is important because you're going to use these keys to differentiate Players through tagging.
Each Player can have one or more tags associated with it. Tags are labels - strings of text - describing something about the Player. It could be location, owner, platform, or anything else that makes it easy to distinguish one Player from another, as well as to identify groups of similar Players. By tagging Players, you can easily filter them, creating targeted groups for specific experience deployments. You are going to do this all the time.
Player tagging is easily performed in the Share and Deploy console. The trick is being able to differentiate one Player from another. Have the Player installer communicate with you the license key for each installed Player; the key is found by selecting the "About this Player" button located in the bottom right of the Experiences panel:
The key enables you to identify the corresponding Player in the Share and Deploy Console. Now tag this Player as needed. Let's say the Player is on an iPad used by a Sales Rep named Steve who works in the northeast territory. Tags could be "iPad", "Steve", "sales", "northeast". Want to deploy an updated sales pitch to all iPads used in the northeast? Now you can, easily, using the tags.
While you're getting this done, your Player installer(s) can check one other thing for you...
In practice, Player installation is the only step necessary to prep a device for playing an experience and being part of a remote deployment activity. However, there are a couple of possible complications about which you should be wary.
- Firewalls and Proxy Servers: It's possible - or, depending on your company, likely - that devices running Player will not have access to the Internet. We have published an article identifying the domains and ports that need to be opened to use features like remote deployment and analytics. Deliver this information to the governing IT Team and request that these domains be permitted access.
- Player Process on Windows PCs: Unique to Windows PCs, Player software is accompanied by an independent Player agent process that runs in the background. Without this agent process, remote deployment (and lots of other things) won't occur. It's unlikely but technically possible that your PC is configured to prevent the creation of this process. To check, open up the Windows Task Manager and look for a background process named "Intuiface Player Agent". If you see it, you're golden. If you don't, share the contents of our article about the Windows Player agent with your IT team.
That's it! Let's deploy something.
Using the Intuiface Share and Deploy Console
The Share and Deploy Console doesn't just facilitate tagging, as discussed above. It enables the entire deployment process. (It also enables sharing, thus its name, but that’s a topic for a different article.) Here's the process at a high level:
- Select the experience you wish to deploy
- Using tag filtering, select the Players you wish to target
- Identify whether you want to push an updated experience to the selected Player devices, play the experience already on the selected Player devices, or push-and-then-play the latest experience
- Optionally identify the date(s), time(s), and frequency of the deployment - aka identify a schedule
- Initiate the deployment
We detail the deployment process and scheduling in our Help Center so they won't be replicated here. What's important to note is the process of defining and initiating a deployment can take seconds despite encompassing what could be hundreds of Players located all over the world. Considering how crucial this activity can be for a project, it's actually quite easy to do in practice.
Wondering why you might want to schedule a deployment? There are a variety of reasons for not initiating the process immediately.
- Avoid experience changes during work hours
- Repeat changes at predictable, regular intervals
- Push changes at hours inconvenient for personnel
- Target Player devices that are offline
Yes, that's right, even offline Players can be targeted. Put simply, Intuiface will "wait" for Players to come online, at which point the deployment will occur. (Well, with an exception. If it's a one-time deployment, this action is queued and will occur once the Player device comes online. If it's a scheduled deployment, any instances of the schedule missed before the device comes online are skipped. Only future scheduled deployments will occur.)
The Deployment API Alternative
Good news for integrators! All deployment capabilities surfaced in the Share and Deploy Console can be accessed through a public REST-based web services Deployment API. Exposure of all capabilities through this API enables the creation of alternative user interfaces, not just in the name of branding, but to present customized views that best complement services delivered to a client.
The API can be adopted at any level of granularity, meaning you can create your own deployment console alternative, visualize Player status, track job queues, and more. As a bonus, more information is available through the API than is presented in the Share and Deploy Console.
The API is free to use and easily adopted – but yes, it still requires coding. That’s the point, offering teams with development skills and motivation to create alternative access to Intuiface deployment features. Satisfied with the existing Console? Great! You can ignore that the API even exists.
As a primer, the goal of this article wasn't to address every nuance. Rather, it was intended to touch on the basics, leaving the details to you for study and discovery thanks to our awesome Help Center and your brilliance.
Remote deployment can make your life SO MUCH EASIER. Even a single Player project can benefit from remote deployment if that device is inconveniently located. Time is saved, headaches are spared, and the world is not denied your excellent work.
With just a little bit of effort, you can become an expert. Show it off to your boss, flaunt it to your family, embrace the looks of confusion on their faces.