The purpose of this document is to clarify the different passwords on a T3 system between the codecs, TCU, and touch panel, list the default sets of credentials for each, and document the procedures for how to change them. Default Credentials for Cisco T3 TCU (VNC / SSH) Username: administrator Password: tec T3 Touch Panel / WebStart GUI Username: admin Password: <blank> TCU Web GUI Username: admin Password: <blank> Note: This cannot be changed as far as I've researched. C90 CLI / Web GUI Username: admin Password: <blank> Changing the TCU password (VNC and SSH) Physically attach a keyboard to the TCU (or log in with VNC) Press Ctrl-Shift-Esc File -> New Task (Run…) “cmd” to bring up a command prompt Type: "net user administrator <new password>" Type: "control userpasswords2". A window will pop up. Check the box “Users must enter a user name and password to use this computer” and Apply Type "control userpasswords2" again, uncheck the box, and apply. Enter your new password again Reboot ("shutdown -r" from the CLI) Page 9 of the T3 admin guide: http://www.cisco.com/en/US/docs/telepresence/endpoint/t3/guides/telepresence_t1_t3_admin_guide_tcu42.pdf Changing the touch panel password (Also WebStart GUI password) Log into the touch panel ( Touch and hold the upper left corner until the login screen appears) Go to Change Passwords Enter new password for Admin or Operator user The Operator user is an Admin user with limited privileges. Make sure you change the dropdown box to Admin to change the correct password. Note: For the WebStart GUI you must use Java 6.x since Java 7.x will not authenticate. The bug ID for this is CSCug84596. Page 23 of the T3 admin guide: http://www.cisco.com/en/US/docs/telepresence/endpoint/t3/guides/telepresence_t1_t3_admin_guide_tcu42.pdf Changing the C90 codec passwords (Web GUI and CLI)                                                                    Either:                               Log into the web GUI Click “Change Password” and enter the new password or Run “systemtools passwd” from the CLI This command will prompt you for a new password Page 16 of C90 admin guide: http://www.cisco.com/en/US/docs/telepresence/endpoint/codec-c-series/tc4/administration_guide/profile-c90_and_codec-c90_administrator_guide_tc40.pdf Page 25 of C90 API guide: http://www.cisco.com/en/US/docs/telepresence/endpoint/codec-c-series/tc5/api_reference_guide/codec_c90_api_reference_guide_tc51.pdf ... View more

Migrating to a new CUCM cluster in CTS-Manager is fairly easy and should not impact meetings. All meeting details are pulled from Exchange and stored in each individual room's mailbox. As each room's "Room Name from Exchange" is the same between the old and new CUCM clusters, nothing will happen to the meetings. Even if all the rooms disappear from CTS-Manager, the meetings would stay in those room mailboxes. When the new CUCM is added, CTS-Manager will rediscover all the rooms from the associated Application User. Then it will look at the Room Name from Exchange configured for each of these rooms, sync the meetings back from Exchange for that room, and the meetings will get pushed back out to the phones Migration Procedure 1. Install the new CUCM, create the device profiles for your endpoints, and create a new Application User. Link to CUCM documentation for CTM. Double check that each Room Name from Exchange field is exactly the same as on the old cluster. Do not associate the MAC addresses with the Application User yet. 2. Turn off meeting notificatations in CTS-Manager under Application Settings -> Meeting Notification Email -> Enable Feature. If you don't, every meeting organizer might get a new confirmation email for their meeting. 3. Make a database backup before any big change like this. 4. Log in to the CTS-Manager web GUI and go to the Unified CM tab. Starting in CTM 1.6, you can add multiple CUCM clusters to a single CTM. Configure the new CUCM cluster with the empty Application User set up in step 1. 5. Migrate the rooms from the old CUCM to the new CUCM. 6. Add the endpoint MAC addresses to the application user on the new CUCM. Remove the MAC addresses from the old user. 7. From the Unified CM tab in CTM, select the old CUCM then click the Discover Rooms. This will empty all the endpoints from the CTM database. Select the new CUCM then click Discover Rooms. 8. Verify the migration went as expected, then turn meeting notification emails back on. Verification After rediscovering the rooms, it will take a few minutes for each room to become synced and for CTS-Manager to redownload all of the meetings. Check the meetings tab to ensure the meetings have been added back to the CTM database. Check the Microsoft Exchange Web Services tab as well and ensure all rooms are synced and subscribed. If any room is not synced or subscribed (and you are sure it was before), double check the Room Name from Exchange in the CUCM Device Profile. ... View more

This article was written because I thought the official documentation at the time was not a great step-by-step resource to send someone you needed to collect SIP traces. The official documentation has since been updated and I recommend you check it out: https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200787-How-to-Collect-Traces-for-CUCM-9-x-10-x.html   This document will focus on collecting traces for CUCM 8.6.2. It should be mostly the same for any recent CUCM release. CUCM traces give us the signalling going across the CUCM as well as give extremely detailed logs of what CUCM is doing when processing calls. It's important to note that traces must be turned on before the problem call/test call is made. If a problem happened once and CUCM traces were not turned on, we cannot go back and get logs.   Configure Traces First, go to CUCM and log into Unified CM Serviceability.     Navigate to Trace -> Configuration     Select the server processing the calls in question. The parameters we're interested in are under CM Services -> Cisco CallManager (Active)       Check Trace On and set the Debug Trace Level to Detailed. Check all the traces relevant to the problem we are experiencing. The most important to have checked is probably Enable SIP Call Processing Trace. Your TAC engineer might ask for other specific traces depending on the issue you're having.       Recreate the Issue   With the SIP traces enabled, recreate the issue. Note the timestamps when you start and stop the recreate so we can find the problem easily in the traces.   Collect the Traces   CUCM traces cannot be downloaded from the GUI. They are collected with the Real-Time Monitoring Tool (RTMT). You can download this from Unified CM Administration -> Application -> Plugins. You might already have a version of RTMT installed, but it's very particular about which version it is compared to CUCM's version. If you find that your RTMT install doesn't work, try downloading and installing the version on CUCM itself.       Click Find then scroll down to the bottom and download Cisco Unified Real-Time Monitoring Tool - Windows       Install RTMT anywhere and launch it. It will prompt you to enter your CUCM IP address. Click Accept if a certificate error appears. It will then prompt you to log-in. The credentials should be your Unified CM Administration credentials.   Click away the Select Configuration window by selecting Cancel, then go to Trace & Log Central -> Collect Files     In the window that appears check Cisco CallManager under All Servers. In certain cases your engineer may also want other services such as Cisco Tftp. Click Next to bring up the next window.         Unless your TAC engineer specifies, you can just click Next on the System Services/Applications window that appears without selecting anything.   On the next screen choose the range when you recreated the problem. Start 5 minutes before and end 5 minutes late to ensure we capture everything in the downloaded logs.     Below this choose the Download File Directory (this is where the files will be downloaded to) and select Zip Files. When you click Finish, the logs will begin downloading. Depending on how many traces were selected, the activity on the CUCM, and the time range, this could take a very long time. Wait until you see completed downloading:     You should have 2 files per server (so 4 zip files total if you have a pub and sub). Upload these files to your TAC service request and please note the timestamp of the issue along with the directory numbers and IPs of the devices in question. ... View more

Unable to validate EWS Connection Error     The most common error when connecting Exchange to CTS-Manager is the error listed below, and it covers an array of issues. "Failed to establish a connection to X.X.X.X with the information provided. Code: 501000... Unable to establish a connection with Microsoft Exchange server because Unable to validate exchange web service connection."       Resolution     To fix this, we need to go through each of the fields under Configure -> Microsoft Exchange Web Services as below.       Check from the CTM CLI that we ping the CAS server with utils network ping [ip_address]. DNS also must be configured and able to resolve the CAS server in DNS forwards and backwards. Check this with utils network host [CAS_ip] and utils network host [CAS_hostname]. If either of those don't resolve, you need to fix your DNS entries   Ensure Secure is selected if we are using an Exchange certificate. In almost almost all cases, we are.   Ensure tcp port 443 is open between CTM and Exchange for Secure mode (80 for insecure mode). There is way to check this from CTM, you need to check your firewall rules.   Ensure the CTS-Manager super user account exists in Active Directory. Reset its password if necessary.   Ensure we are using the correct certificate. The best place to download this from is https:// [Exchange_IP]/EWS/Exchange.asmx . If this page comes up, you also ensure EWS is running (Note: You do not need to sucessfully log in to download the cert). To download the certificate from Internet Explorer, go to the above URL and click the lock icon or Certificate error (depending on your version of IE). Click View Certificates and go to the Details tab. Click Copy to File... and save the cert as a DER encoded binary X.509 (.CER) file. Upload the certificate to CTS-Manager.     ... View more

Symptoms / Verification If you have Cisco 12" Touch Panel on a CTS or TX-series endpoint during a new install that is stuck on "Establishing Connection", it could be an issue with the Manufacturing Installed Certificate. Occasionally, this is missed in manufacturing and the MIC has to be regenerated. The touch panel will boot up fully, it will not get stuck on any checkpoint. The full error that will be on the panel is Establishing Connection Attempting to connect with the system. Please wait a moment. We can verify that this is a MIC issue by typing show cert mic in the admin CLI. You should receive an error that says there is no certificate. You can also check the Log Files setion of the GUI. There should be a very clear error at the top of the sysop log files as below: ****************************** WARNING= No valid Manufacturing Installed Certificate found Secure mode operation may not be possible ****************************** If you are attempting to register to a secure device profile, the registration will fail without the MIC installed as well. Resolution The easiest way to resolve this problem is with a factory init or factory reset of the codec. This will clear all configuration (including IP and CUCM configuration) and regenerate the necessary certificate. You can follow the factory reset guide here, simply replacing "utils system factory reset" with utils system factory init. A factory init is the same thing as a factory reset, but it doesn't roll back the running code to the factory slot. If you are not onsite or otherwise unable to wipe the IP configuration from the endpoint, you can also open a TAC case to have the MIC recovered. We can run a root script to regenerate it which will just require a reboot. ... View more

There are few steps in an Exchange 2007 to Exchange 2010 migration as detailed in the Cisco.com documentation, however there are some troubleshooting steps that may resolve some issues should there be a problem during the migration: Prerequisites CTS-Manager is at least version 1.7, the minimum to support Exchange 2010. One should consider upgrading to at least 1.7.4 to avoid issues with recurring meetings. Have the Exchange CTS-Manager super user account credentials and Exchange 2010 Certificate available. The super user account is often named something like "ctsmanaccount". The certificate can be downloaded in DER format from https://EXCHANGE_IP/EWS/Exchange.asmx from any browser. DNS is configured in CTS-Manager under System Settings. Verify that we can resolve the hostname of the new Exchange 2010 CAS with utils network host [CAS hostname]. DNS must be configured for CTM to connect to Exchange without issues. If we can't hit the DNS server, look into network issues and ensure port 53 is open. CTS-Manager can ping the new Exchange 2010 server and that port 443 is not being blocked on a firewall. CTS-Manager is already configured with Exchange 2007 EWS. If we are currently using 2007 with WebDAV, we need to move over to EWS per the Deploying with Microsoft Exchange 2007 and 2010 EWS guide. Set the Exchange 2010 throttling policy per this documentation: Applying CTS-Manager Throttling Policy for Exchange 2010 SP1 Migration Procedure Link to Cisco.com documentation: http://www.cisco.com/en/US/docs/telepresence/cts_manager/1_8/admin/ctm_instalMS.html#wp1102026 Shut down the CTS-Manager from System Settings -> System in the GUI or "utils system shutdown" in the CLI. Before doing this make sure someone can turn the server back on either remotely on onsite. Migrate the CTS-Manager super user account mailbox (ctsmanaccount) from Exchange 2007 to 2010. Migrate the TelePresence room mailboxes from Exchange 2007 to 2010. Wait for everything to migrate over successfully. Turn on and log into the CTS-Manager GUI. Under Configure -> Microsoft Exchange Web Services -> Configuration, add the new hostname of the CAS server or CAS array. Use the credentials for the CTM super user account. Upload the new certificate for the 2010 CAS. Click Test Connection. If it fails to verify, check everything under the prerequisites carefully. Click Apply. Note: If the Exchange connection "is verified" and applied but still shows in error in the GUI, try restarting CTM. After the reboot, it should sync the rooms correctly. Verification To verify that the Exchange migration has gone as expected, check the following: The Sync status in the GUI, under Configure -> Microsoft Exchange Web Services -> Configuration, should be green for all migrated rooms. Schedule a test meeting with the migrated rooms. If you don't get auto-accept emails back, this is an Exchange problem, so check the auto-accept configuration on that end. If you don't get the CTS-Manager confirmation email within a reasonable period of time, check that the CTS-Manager super user has Full Access priviledges to all rooms. Important Note: It can take as long as 30-60 minutes following a migration for Exchange to fully sync up the new rooms. If some rooms don't send auto-accept emails right away, wait a half hour and schedule another test meeting before assuming the migration has failed. Cisco.com Documentation: http://www.cisco.com/en/US/docs/telepresence/cts_manager/1_8/admin/ctm_instalMS.html#wp110202 ... View more

A number of issues can cause either a CTS codec or phone to be Unregistered or Rejected in CUCM. Basic Configuration 1. Try to ping the CUCM from the codec using "utils network ping". If you know ICMP isn't being blocked on the path and you can't hit it, the first step should be to investigate network or DNS resolution issues. 2. Ensure port 6970 is not blocked. This is required for most telepresence devices to download their configuration file from the CUCM. Phones use UDP port 69 for TFTP. 3. If using DHCP, ensure DHCP option 150 (TFTP) is enabled and includes the IP of the correct TFTP server. On the codec, check Configuration -> Unified CM to ensure the codec is pointed at the correct CUCM. On the phone, check Settings -> Network Configuration -> IPv4 Configuration -> TFTP Server 1. 4. Ensure the correct MAC address is set under the CUCM device profile. For the codec, this can be found in the GUI under Device Information. For the phone, this can be found under Settings -> Model Information. 5. Ensure both the codec and the phone have a Directory Number set, and that it is the same DN. 6. Ensure the access switch is not using the same number for the data and voice VLAN. For example, do not use both "switchport voice vlan 10" and "switchport access vlan 10". 7. If this is a new CUCM install, ensure the Call Manager and TFTP services are running under Unified CM Serviceability. 8. If registration is bouncing, ensure we do not have a duplicate IP address on the network by shutting down your device, then trying to ping the device's IP address. 9. Are the codec sysop logs very sparse in regards to registration messages? In the SIP logs on the codec, do we see a SIP/2.0 404 Not Found that says Warning: 399 cucm_hostname "Database error" ? In previous cases, this issue has been resolved by rebooting CUCM. 10. Are we seeing registration rejected on a new codec/phone or one that refreshed its CTL? Do we see ERROR Config file rejected: signer in the Sysop logs of codec? This could be a CUCM issue where the serial numbers between the CTL installed on the codec and the CUCM CTL are different. To fix this we need to rerun the CTL client from the CUCM. Codec Specific Issues 1. If we see Registration Rejected on CUCM, and the codec was recently replaced or switched CUCMs, try refreshing the CTL. From the GUI, under Configuration -> Unified CM, try pressing the Delete CTL button. If this works, the button will become grayed out. If it does not, we'll need to delete the CTL from the command line. Log into the CLI and run Adv Mode (case sensitive) followed by utils security clear. 2. Is the directory number 7000? This means we are in DEMO mode (Non-CCM mode). Verify this in the CLI with show config system. If you see "CCM Mode : NON-CCM", then a step was missed at the factory. Open a TAC case to get this resolved. 3. Are you failing to register to a secure device profile? The step to install the manufacturing installed certificate might have been missed at the factory. Check with the show cert mic command. If it shows there is no installed MIC, open a TAC case to get this resolved via root. You can also factory reset the endpoint to fix this. 4. Do we see Registration Rejected from CUCM or a 485 Ambiguous "Device Type Mismatch" SIP message? There's a good chance the device profile is set to the wrong device type. This is most common with CTS-1300-65s and TX-1300s (or CTS-1300-47). These endpoints use entirely different codecs and must be set correctly. There is no way to change the device type of a profile, the profile will have to be deleted and recreated. Alternatively, if all other troubleshooting fails, this might be fixed by setting the cts type manually to avoid this mismatch. Do this with set ctstype [type] from the CLI, where type is the endpoint model number such as 1300 or 3200. 5. Is the registration bouncing between Registered and Unregistered? This could be an issue with the cameras connected to the codec. The codec will not register unless all of the cameras are healthy. Check the GUI, are any of the cameras in error under System Status? If so, try reseating the camera cables at both ends. If the issues persist, open a TAC case and try to isolate the camera problem. Phone Specific issues 1. Was this phone recently replaced, factory reset or is it a new install running a SCCP phone load but trying to register to a SIP profile? The phone should first be upgraded to SIP 8.4(4) and then to a higher SIP load such as 9.2(3). See this article: https://supportforums.cisco.com/docs/DOC-23041 2. Was this phone replaced did it change CUCMs? Are we seeing Registration Rejected? Delete CTL from the phone by going to Settings -> Security Configuration -> Trust List -> CTL File. Hit * * # on the keypad to unlock the settings, then select Erase. There is no way to do this remotely. Cisco.com Documentation Troubleshooting Registration: http://www.cisco.com/en/US/docs/telepresence/cts_admin/cts_troubleshooting/cts_trbl_registration.html CUCM Configuration for CTS: http://www.cisco.com/en/US/docs/telepresence/cucm_cts/cucm_cts_admin_book/guide/cucm_cts_admin_config.html DHCP Option 150: http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/dhcp.html#wp1059719 ... View more

TelePresence echo can be caused by a number of things. To effectively troubleshoot the issue, your TAC engineer will need to know the following: Who in the call hears the echo? Does the local endpoint hear its own echo? Does the local endpoint hear reverb from the remote endpoint? Does the echo consistently occur on every call? Is the echo only between certain endpoints? Did something trigger the echo (Software upgrade? Endpoint moved?) Has the room experiencing echo passed CTX certification or a Room Readiness Assessment (RRA)? Echo issues are often caused by the room environment at the remote site. Reverb can be caused by the audio channel being out-of-sync. Configuration Issues 1. The first thing to check is your configuration. In the CUCM device profile of the codec itself make sure Acoustic Echo Cancellation (AEC) is enabled. If it wasn't, check it and save/apply the config. 2. Also ensure you have the correct Microphone Count configured in the device profile if you have a CTS-1300. 3. Make sure the Volume on the phone in each room is set to 7; this is the recommended level. 4. If you're experiencing echo on a standards based endpoint (C-series/EX-series/MX-series, E20 and Movi) when natively calling a CTS running 1.7.4 - 1.8.0, you could be hitting a bug (CSCts48847). Microphone Issues 1. First, ensure that the microphones are cabled correctly. The center mic should be connected directly to the center codec. The other microphones connect to the audio/video expansion box. The below diagram is for a CTS-1300, but is relatively similar for a CTS-3000 (which does not have positioning mics). 2. If the microphones are wired correctly, run a microphone calibration. Do this from the CTS web GUI. Go to Hardware Setup -> Microphones -> Start. From here you will be able to run a microphone calibration Hit the Test button to begin the mic calibration. The room must remain quiet! The ambient noise levels in the room should be what they normally are (e.g. noise from a busy street is OK if it's normally present). The calibration will take a couple of minutes. 3. In CTS 1.9.0, you can run CTX certification tests from the GUI. Under the same Hardware Setup -> Microphones screen, there is a CTX tab at the top. From here you can run Reverberation and Noise Level tests. Run each of these tests and record the results. The reverberation test will chirp at different frequencies and measure the sound decay time in milliseconds. Reverb Test Decay Time Action 150 - 300ms Ideal 300 - 500ms Cause for concern. The issue should be addressed. 500ms or more May cause significant impact on TelePresence calls. The noise level test measures the sound pressure in the room at various frequencies in decibels. Sound Pressure Action Under 36dB Ideal 42 - 50dB Cause for concern. The issue should be addressed. 50dB or more May cause significant impact on TelePresence calls. 4. To troubleshoot the hardware itself unplug and test the microphones one at a time and make test calls to see what configuration of microphones causes the echo issues. Try each microphone in each port. Is any one microphone consistently causing the issue? Is any one port (on the AEB or codec) consistently causing the issue? Does the issue only occur when multiple microphones are plugged in? Let your TAC engineer know if the issue follows a particular microphone, port, or neither. CTMS 1.8.0 - 1.8.3 bug If you are experiencing reverb issues only on multipoint calls through a CTMS 1.8.0 through 1.8.3, you could be hitting this bug: CSCua92152. The bug is that CTMS is not sending service reports (SRs) in RTCP packets. These are used to calculate jitter buffers and buffer occupancy. Without receiving RTCP SRs, the audio sync won't happen and the relative delay between audio receivers will be heard as reverberation. Under good network conditions (with QoS properly implemented) the problems are less likely to occur. The more jitter we have, the worse the issue will be. The resolution is to downgrade to a 1.7 release or upgrade to CTMS 1.8.4. If you see your QoS markings on calls are [BE] (best effort), this means DSCP markings are being stripped off somewhere along the media path. You should also fix your QoS implementation which could mitigate the impact. Resolving Echo Issues If it's determined there is too much reverb or noise in a room, the issue will have to be mitigated somehow to decrease or eliminate the echo. A common fix for this is adding staggered acoustic paneling to a room so that no bare wall faces any other. Additionally, one can add sound damping objects such as plants If you have gone through the above troubleshooting and still have echo issues, please collect the results from above and full CTS logs and upload them to your TAC case. Cisco.com Documentation http://www.cisco.com/en/US/docs/telepresence/cts_admin/cts_troubleshooting/cts_trbl_av.html http://www.cisco.com/en/US/solutions/collateral/ns669/c07-643449-00_tp_dg.pdf ... View more