If you're having VSys One and VSys Live hosted by us, none of this is applicable to you: it's already taken care of!
Because installing VSys Live is a deep project, and one that your IT department will do only a few times, the VSys One team is happy to do that installation for you. There are certain technical requirements that must be met first, though. (Keep in mind that these requirements, with the exception of SSL certificates, external DNS entries and port forwarding, apply to your test environment as well.)
At the very least you'll need one external DNS entry for each VSys Live machine. If you're using VSys Live and VSys Live Kiosk, each of these will need its own DNS entry. (They can share a single external IP address.)
You should have internal DNS entries for VSys Live as well. If multiple VSys Live sites, e.g. VSys Live and VSys Live Kiosk, are on the same machine, they must be accessed via name rather than IP address.
Use simple names for VSys Live and VSys Live Kiosk where possible. For example, vsyslivekioskprod.something.local is nowhere near as user-friendly as kiosk.something.local, and it's unlikely to collide with any other devices. If you want to distinguish test from prod machines, make the test URL longer, e.g. kiosktest.something.local, since it won't be used nearly as much.
Some organizations don't allow workstations on the internal network to access machines in the DMZ. That will make testing much more difficult.
Our team will need:
"Superuser" rights in VSys One itself.
External RDP (Remote Desktop) access to the physical or virtual machine that VSys Live will be installed on. Optionally, using an external vSphere interface is possible, but more complicated.
Windows login credentials for that machine. These credentials must allow:
Login and db_ddladmin rights on SQL Server to the VSys One database,
Installation, removal and start/stop of Windows services.
Windows and SQL Server credentials for the VOXI service. These should be different from the user credentials above.
A mechanism for installing files on the machine. This may be copy/paste via RDP or access on both ends (upload externally, download from VSys Live machine) to an FTP site. Having your IT team add files for us is not a feasible alternative to this.
If you plan on building out the VSys Live environment within your internal network, then migrating to the DMZ later, keep a few things in mind:
Using domain credentials for the machine and SQL Server access is great! But if you're going to take the machine off the domain, or transfer it to a different domain in the DMZ, there's going to be a lot of cleanup work after moving it.
SQL Server connections that worked outside of the DMZ probably won't work when the machine is moved.
All or most of the VSys Live installation settings will be have to be changed after migration.
Best advice: build out the VSys Live machine where it'll actually live long-term.
Once VSys Live is up and running, it is helpful for our team to continue to have remote access to the VSys Live machine: this makes diagnostics, maintenance and updates much simpler. It's not required, however, and you can terminate our remote access once the project is complete. Be aware that if problems occur, we'll ask you to re-enable that for us to diagnose and fix any issues.