Automating the reboot of Polycom meeting room devices

If you have found your way here then you have walked the painful path of failed meetings and angry Execs. Suffice it to say that some (read: all) Polycom video conference units get cranky after a while and need to be rebooted lest they begin to forget their only reason for existing.

Below is a very simple method for automating the reboot of such units. There is an alternative method that one could use using Python scripts (or Cygwin). But if you don’t fancy having to install the bits to run Python scripts nor having to learn Python then this would be your low-tech guide 🙂

Lets’ start with the basics:
There is an API guide for Polycom RealPresence devices.

Polycom units are accessible for remote management via an SSH connection on port 22. Unfortunately the SSH and shell that the Polycom runs is non-standard and, as such, does not support the automated remote execution of commands or scripts using the ssh client (either on Unix or in Cygwin). Therefore some wrapper for SSH is required. In this case I tried Putty but it had limited ability to execute arbitrary commands upon login. A fork of Putty is known as Kitty and it had two useful options:
Polycom units are accessible for remote management via an SSH connection on port 22. Unfortunately the SSH and shell that the Polycom runs is non-standard and, as such, does not support the automated remote execution of commands or scripts using the ssh client (either on Unix or in Cygwin). Therefore some wrapper for SSH is required. In this case I tried Putty but it had limited ability to execute arbitrary commands upon login. A fork of Putty is known as Kitty and it had two useful options:

• Run commands on login
• Save login password

The latter is clearly not ideal but the Polycom shell does not seem to support the generation of ssh keypairs etc and so a password has to be supplied. The mitigations are as follows:

• Passwords and any settings are saved in in a Putty/Kitty profile. This profile is stored in HKLU and so should only be accessible to a service account used to create the profiles and local admins.
• The profiles are only stored on a secured management server. The Putty/Kitty Profiles

NOTE: You will need to run each saved connection at least once manually in order to trigger and accept the certificate presented to the SSH client by the Polycom.

Preparation

1. Create a service account in Active Directory (or locally if you are a workgroup environment)
2. RDP to the server that you want to run the automation from.
3. Edit the local security policy (secpol.msc)
4. Grant the account from step 1 the “Log on as a batch job” right.
5. Create a folder on an appropriate drive and name it “Kitty” (e.g. D:Kitty)
1. Grant the account from step 1 NTFS Modify permission on the folder
6. Download the non-portable version of Kitty
1. Move the file to D:Kitty
2. Run the Kitty.exe file as the service account and create the required Putty/Kitty profiles as follows:ii. “n” is the delimiter between commands

iii. “reboot y” triggers a reboot and confirms yes to any prompts (better than using “reboot now”)
iv. “exit” then exits the ssh session. This is required because until that session exits, the scheduled task still thinks it is running.
Scheduled Tasks

The Putty/Kitty profiles

1. Session > Host Name: Set this to the IP of the relevant Polycom unit
2. Session > Saved Sessions/New Folder: Use the “ Polycom” naming convention e.g. “Schneider Polycom”
3. Connection > Data > Auto-login username: admin
4. Connection > Data > Auto-login password: set this to the polycom password
5. For each profile load/run it in the Kitty GUI. The first load will trigger the following prompt:

6. Click OK
7. Close the connection. The profiles are now prepared

Now we need to do a last round of configuring the Kitty profiles:

Note that doing this configuration after steps 1-7 is essential as we don’t want to reboot our units prematurely.

1. Connection > Data > Command: s05 n reboot y n exit
   waits for 5 seconds after establishing the connection
1. “s05” waits for 5 seconds after establishing the connection
2. “n” is the delimiter between commands
3. “reboot y” triggers a reboot and confirms yes to any prompts (better than using “reboot now”)
4. “exit” then exits the ssh session. This is required because until that session exits, the scheduled task still thinks it is running.