"" aka rugged (as of 2013) is a Windows KVM guest running the Scopia XT Desktop software for video conferencing. The software communicates with the Scopia XT1000 hardware videoconferencing device sited in the instrumented meeting room. It was set up in accordance with RT:62264.

This software runs on a DICE KVM host (presently craggy) for ease of management, which lives in the Forum server room.

Documentation on the Scopia videoconferencing system can be found at Radvision:

External support for the box is provided by Videonations, and they can be contacted by phone or email. You will need to quote the serial number of the box.


  • The XT1000 device's web interface can be found at; this largely mirrors the on-screen display of the device.
  • The XT Desktop administrative interface can be found at
  • The Windows server on which the XT Desktop software runs can be accessed via KVM console (using virt-manager) or restricted RDP (using rdesktop on DICE).


Very little of importance is stored on the server; backups are retained for the purpose of simple DR reinstatement and configuration safety. The Scopia software needs only minimal configuration (largely, pointing to the XT1000 box); beyond this the most complex configuration is to the Windows Firewall since extensive internal communication is required between the server and the XT1000 device. This is described in the initial RT and it's anticipated that recreating this configuration on a fresh install will be simpler than attempting a restore.

Nonetheless, backups of the system disk are taken regularly by NTBackup onto drive K:, actually partition on the same virtual disk. From there they are mirrored [TBC] onto DICE hardware.

Restore Process

Restoration of the VM host is trivial as it is a DICE server without any configuration beyond its profile, though it will require the guest to be restored thereafter.

The VM guest can be recreated following the kvmtool command in its profile, and installation performed by booting from the Windows Server DVD referred to in the machine profile. Whether restoring from backup or reconfiguring from scratch, this is a mandatory step.

As suggested the recommended restore process is simple reinstallation of the Scopia Desktop software followed by configuration of the Windows Firewall according to the initial RT specification. However it might be useful to examine the backups taken by Windows backup by copying the contents of the backup volume back onto some free space / an empty partition on the reinstalled hardware.

Logging In

Web interface usernames and passwords can be found with members of the RAT unit. RDP-based access is also available but should not be required for routine front-line support.


In general we do not anticipate performing routine maintenance on the Windows server and software other than occasional checks, as it should be entirely automated. However some intervention might be required from time to time:

Software Updates

These are completely automated; reboots, where necessary, are typically scheduled by Windows at about 0300.

Restarting the server

The Scopia software is not 100% reliable and intervention has been required on several occasions already. A scripted restart has been set up so that, in theory, a failing service should be restarted automatically (and a ticket following the format of RT:64654 created in the RAT queue). In practice this doesn't seem to work, presumably because the failing service doesn't truly terminate.

In the event of any failure, the easiest thing to do is therefore simply to restart the Windows server, as this can be done simply via DICE using the standard KVM instructions:

$ rvirsh <host> shutdown <guest> --mode acpi   # (host presently 'craggy'; guest 'rugged')
<wait for shutdown to complete, usually 1-2 mins...>
$ rvirsh <host> start <guest>

You can monitor the process (or do the shutdown manually) by examining the (graphical) machine console with the virt-manager tool. If the guest is failing to shut down, connect to its console with virt-manager and attempt to find out why (or at least where) it's stuck before forcing a poweroff with rvirsh [...] destroy.

Apart from this we've noted a single instance where the Scopia service failed to start following a (forced) Windows restart during which the Scopia box was offline.

Restarting Services

If restarting the server hasn't worked, it appears that it's occasionally necessary to restart the Scopia services individually (It's not clear if this is a startup race condition or just fluke as it happens very rarely and nothing interesting is logged).

In any event, the procedure for restarting services is relatively straightforward. From a DICE desktop log into the machine using rdesktop cstrconf (you might find it less frustrating to increase the screen resolution using the -g option, e.g. rdesktop -g 1280x1024). Having done this you'll be presented with a login screen:


Log in using the credentials provided by the RAT unit; you'll be presented with the Server Manager:


The dashboard view can be quite confusing; best go straight to "Local Server" in the left bar to investigate any error events, consulting RAT if they're hard to interpret (pictured here is an example of an ignorable warning):


Scroll down the main panel of the application to find the services. You can scroll through the services list, or filter by name:


here you should examine the two SCOPIA services. From here you can right-click to stop and restart these services:


Often this is sufficient! Otherwise, it's worth looking through available event and on-disk logs, and also checking for services whose Start type is "Automatic" but which are not running.

-- GrahamDutton - Dec 2013

Topic revision: r7 - 11 Dec 2014 - 12:47:43 - GrahamDutton
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies