How to enable debug logging on RW20 using Admin Console
When verbose logs are required to troubleshot an issue the following procedure can be used to enable debug logging and retrieve the files.
Double click on the desktop icon for the Admin console or select it from the start menu.
Select the unit(s) from which you require verbose logs.
On the right side panel under property on the Configuration tab, change Debug Logging to On
Right click on the unit, select firmware and then Reboot Unit(s)
Configuring the RoomWizard for debug logging is not retroactive, so after the unit comes back up you will need to wait for the problem you are troubleshooting to re
Wait 5-10 minutes to make sure that the logged data has been flushed to the disk (SD card on the RW20).
Right click on the unit, select LogFiles and then select Download all logs.
This will create a zip file on your desktop. Wait for it to completely download the file before emailing or transferring the file to Tech Support
Exchange Schema Validation Error
Microsoft’s Active Directory schema contains formal definitions of every attribute that can exist in an Active Directory object. The Steelcase Exchange Connector also connects with Active Directory when getting bookings for an account to verify it exists in your AD forest. LDAP Login Details are required when Active Directory is hosted in a different domain than the Exchange server. If both Exchange and Active Directory are in the same domain, LDAP Login Details are optional.
To successfully verify the account exists in your AD forest, the Connector Configuration requires the Fully Qualified Domain Name in all “Domain Name” fields as well as an accurate server name for your Active Directory server in the “Server Name” field under LDAP Login Details of the Connector Configuration.
Below is an example of the error you may encounter:
The bullets below will show you what you should check when encountering this error:
- Does the account reside in the same domain as all your other RW Resource accounts?
- Does the “Server Name” field in your Connector Configuration include the Active Directory server that the Resource Mailbox accounts reside on?
- Does the account mailbox reside in the same Exchange database as the other resource accounts that you are using for your RoomWizards?
- Does the Room ID match the sAMAccount Name in Active Directory of that particular mailbox which is the same as the pre-Windows 2000 logon name?
- Does the “Domain Name” field in your Connector Configuration include the Fully Qualified Domain Name of your Domain forest?
- In some rare cases, depending on your environment, the EWS URL may also require the FQDN with the Exchange CAS server
RWAC Configurations for HTTPS
By default, RoomWizards are accessible over HTTP. RoomWizards are accessible over HTTPS as well if a secure network if desired. If HTTPS is enabled, HTTP is disabled, as RoomWizards cannot be set to both HTTP and HTTPS at the same time.
RoomWizards that are configured with HTTP will be accessible over the RoomWizard Administrative Console. However, RoomWizards that are configured with HTTPS will not always be accessible over the RoomWizard Administrative Console. This issue is described below and workarounds are suggested in case this issue occurs.
- Handshake Protocol: HTTPS RoomWizards that are running FW 22.214.171.124 are configured to authenticate HTTPS requests utilizing a handshake with the TLS 1.2 Protocol. This is necessary to maintain the latest security standards on the RoomWizard. The RoomWizard has thus disabled handshake protocols attempted over SSL and TLS 1.0. TLS 1.1 is still available.
- Due to the recent handshake algorithm change it is observed on occasion that PCs or Servers attempting to authenticate with HTTPS RoomWizards will be unable to connect to the RoomWizard using the RoomWizard Administrative Console. This issue is caused by the Windows system utilizing a TLS 1.0 handshake rather than a TLS 1.2 handshake. Systems configured to use TLS 1.0 will thus be unable to connect to RoomWizards running FW 126.96.36.199 using the RoomWizard Administrative Console.
When this issue occurs either after a RoomWizard Firmware upgrade or a possible PC change, the RoomWizard will appear offline in the RWAC. The RoomWizard is still accessible and able to perform SSH or FTP specific functions but cannot display any RoomWizard Administrative Console settings that require accessibility over HTTPS. Therefore, it is observed that specific RoomWizard information displayed on the Configuration, Properties, and Status Tabs is missing and blank:
Implementing fix for this issue
Correcting this issue involves editing the Registry to force Windows to use TLS 1.2 handshakes before attempting TLS 1.1 and TLS 1.0 handshakes.
NOTE: This should be done with caution as Registry changes could affect the stability of the PC and Server and possibly corrupt the system if the steps are not followed accordingly. Further this fix could cause other applications using TLS 1.0 to no longer function. Since SSL is already disabled on most Windows systems SSL based applications would not be affected by this fix.
To edit the Registry:
- Click the Start button
- In the Start Menu, either in the run box or the Search box type Regedit and press
- Once the Registry is loaded, expand the following: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework
- The default values are displayed below
To proceed with the fix, add a DWORD and name it SchUseStrongCrypto and set it to a hexadecimal value of 1. The result will appear below
- Repeat this step by adding this value to a second
- Once complete collapse all Registry containers and exit the
- After these steps are complete all HTTPS RoomWizards running FW 188.8.131.52 will be accessible via the RoomWizard Administrative Console.
- Once the fix is implemented it is observed that the RoomWizard running Firmware 184.108.40.206 is now being displayed in the RoomWizard Administrative
NOTE: This issue can be resolved by downgrading to Firmware 4.6 as this version accepts TLS Version 1.0 handshakes. This solution is not recommended because this Firmware version is less secure than Firmware 4.11.0
How to rebuild an RW20 Device
To rebuild the device through the web page
If you can access the web page for your RW20, browse to “Language” and select “Restore factory settings,” then click on “Save on THIS Wizard.”
If you cannot access the web page of your RW20, you may access the device via SSH.
To rebuild the device through SSH
A login prompt will appear on the RoomWizard
Login username = root ; password = Company set password or Steelcase Default*
Type the command: cd /opt/sbin to browse to the sbin directory
Type the command: ./rebuild.sh to rebuild the device.
Lost or Forgotten Password
RoomWizard can be accessed via the "root" account using a password and most/all of the function of the RW can then be accessed once this account connection is established. Until very recently (12/2016) most RWs were left in their default condition with respect to root password. The default PW, "ScRwPw01" was to be used by Tech Support and system Administrators to administer and debug RWs. Very few customers were changing the root PW. Over time, this password became "general knowledge" and left RWs vulnerable to anyone who might want to access them using this PW. As part of a Security Initiative by Steelcase, it was decided that we should encourage Customers to change their root password. In support of this effort, two main things were done:
- A letter was sent to known customers and dealers advising them to change their root password (along with instructions on how to do so using RWAC)
- RWAC was modified
- To give a visual indication when the default root password is still in use on any monitored RW (by means of an exclamation mark in conjunction with the RW Icon in the RW list)
- To provide some new, more intuitive, means to change the root password. (See below for more details)
Changing the root password comes with some acceptance of responsibility in remembering the new password. The decision was made to NOT retain any "backdoor" because of the risk of that information leaking out and creating the same situation we had in the first place. So, losing track of a changed root password now has the potential to render the RW inaccessible for administration, modification, or debugging.
RoomWizard has two main types of access accounts.
- Root PW can be used under most circumstances to gain full access to the RW. It can be used for FTP/SFTP access, SSH access, and the root password also unlocks the Admin Pages on the front panel of the RW. The default for this PW is "ScRwPw01"
- There is also an Admin PW which can be used when accessing the Admin Pages of the RW from the Front Panel (either via WEB or Physical Device). The default for this PW is "79201"
Changing passwords directly on RW
Only the Admin PW can be changed by accessing the Admin Pages on the RW. The option is found one the Device/Security page. This is not the recommended way to change the Admin PW.
To change the root password directly, a user must first log in (via some Telnet type application such a PuTTY) suing the existing root account. Then, there is a script available to change the root pw in the /opt/sbin folder. This is NOT a recommended option as it leaves no safeguards to avoid losing the new password.
For both passwords, changing via RWAC is recommended instead of direct RW manipulation.
Changing via RWAC
Changing either the Admin or root password can be done using RWAC and is the recommended method. For the root password, RWAC will actually keep an encrypted copy of the password when it is changed so that the user does not have to reenter the password each time an operation requiring root access is attempted. This is a service for the user and should not be considered a fool proof way to keep track of a change root password. The user is ultimately responsible for keeping track of all changed passwords. The following is a document which describes how to change the root password on an RW.
The Admin password can also be changed using the RWAC. This file is stored in the Data folder off the RWAC exe folder and is called credentials.xml.
Also, it should be noted that the local list of PWs is kept on a per instance of RWAC basis and if a separate RWAC is run on a different PC, it will have to build up its own local copy. Additionally, if RWAC is uninstalled and reinstalled, the local list of PWs will be reset and thus any stored information will be lost.
As of RWAC 1.4 and later provisions will be made to allow a user to save both the RW list and the associated PW list when a File/Save operation is done. This will facilitate both transfer of the RWs and PWs lists to another instance of RWAC or to save across an uninstall/reinstall operation. In this case, the saved credentials list will actually take on the filename of the save RW list but with the extension ".cre" (e.g., saving with filename "BuildingA" will result in two files, BuildingA.xml (RWs list) and BuildingA.cre (PWs list))
Therefore, if using RWAC 1.3 or earlier, it is up to the User to purposefully save the credentials.xml file whenever undertaking any operation which might change or reset it.
Recovering from a "lost" root password
Under some circumstances, one can encounter a situation where the root PW is "lost" in that neither the User nor RWAC seems to know the right PW to use. In this case, there are some steps which can be taken, but none are very pleasant.
If the root PW was changed using RWAC, then the encrypted PW would be stored in a local file (under the Data folder off the RWAC exe folder) called credentials.xml. Under this circumstance, the PW should not be "lost" unless the credentials.xml file is lost or overwritten. This can happen during an uninstall/reinstall when upgrading to a new RWAC. Prior to RWAC 1.4, this file must be manually saved by the User to avoid losing the local PW list. After 1.4 is installed, the File/Save operation will automatically save both a copy of the RW list and the credentials list.
Knowing this, and knowing that the credentials.xml file must have, at one point, contained the "lost" PW, if the PC hosting RWAC has daily backups, there is the chance that the credentials.xml file could be restored from a backup.
If it is determined that there is no viable path to recovering the "lost" PW via RWAC, then that leads us to a much less desirable option. Assuming that the Admin PW has either not been changed or that it is not also "lost", then the User can access the Admin Page (Device/Language) and cause a Factory Reset of the RW. By doing this, the RW will return to its factory conditions including returning both root and Admin PWs to their defaults. At this point the RW is fully accessible again using the default PWs.
If the Admin PW has been changed and is also "lost" then the RW is rendered inaccessible and must be re-flashed to restore usability. Re-flashing is not a field operation so likely the RW will have to be returned to SC in this circumstance.
Running RoomWizard Connectors through a Proxy
When running a Proxy Server in your environment, the following code must be added to the Web.Confg file for the connector to be able to communicate properly:
Exchange RoomWizard displays details of Meetings marked Private
Users may want to keep confidential the details of a meeting and the list of invitees to some meetings. To accomplish this, the most common method is to mark their meetings “Private” in Outlook:
However, the Exchange calendar may be set up to delete the “Private Property” from meetings. If so, the RoomWizard will display the details contrary to the desires of the meeting organizer.
Note: this unit has the Subject displayed larger than the meeting host/Organizer. For units with that front panel option not selected, the meeting organizer will be in the large font.
And by pressing the “Details” button on the device, you will see the list of attendees contrary to the wishes of the organizer for a private meeting.
To correct the issue for Exchange 2010:
Open the Exchange Management Console.
Under Recipients à Mailboxes, open the Room Resource properties by double clicking on the room name or right clicking on the room name and selecting properties.
Select the “Resource Information” tab
Deselect the check box that reads, “Remove the private flag on an accepted meeting”.
Booking shows Organizers name instead of Subject
Consider the following scenario:
- A Resource mailbox is configured to AutoAccept in a Microsoft Exchange Server environment.
- You send a meeting request to the Resource mailbox.
- The meeting request is accepted automatically, and the meeting subject is displayed correctly in the organizer's mailbox.
In this scenario, when you log on to the Resource mailbox, you see that the meeting subject is replaced with the organizer's name.
This is default behavior. It occurs because
DeleteSubject are set to True.
To view these value for the Resource mailbox, run the one of the following cmdlets:
For Exchange Server 2016,Exchange Server 2013 or Exchange Server 2010PowerShell
Get-CalendarProcessing -Identity <RESOURCEMAILBOX> | FL
For Exchange Server 2007powrshell
Get-MailboxCalendarSettings -identity <RESOURCEMAILBOX> |FL
To resolve this issue, follow these steps:
- Open the Exchange Management Shell.
- Run the one of following cmdlets:
For Exchange Server 2016, Exchange Server 2013 or Exchange Server 2010PowerShell
Set-CalendarProcessing -Identity <RESOURCEMAILBOX> -DeleteSubject $False -AddOrganizerToSubject $False
For Exchange Server 2007PowerShell
Set-MailboxCalendarSettings -Identity <RESOURCEMAILBOX> -AutomateProcessi