•  Streamlines configuration and ongoing management of large Riverbed product deployments.

•  Simplifies configuration management with flexible group features to deploy consistent configurations to a specific location, business function, or a preferred grouping.

•  Provides cluster management for the SteelHead Interceptor appliances.

•  Facilitates configuration by automatically deriving all application path possibilities across all SteelHeads in your deployment.

•  Provides flexible reporting on performance improvements for the entire SteelHead deployment, specific groups, or individual SteelHeads.

•  Reports on bandwidth usage, bandwidth compression, and specific performance of particular ports, applications, and appliances.

•  Displays a centralized view of the overall health of all appliances in your deployment.

•  Provides global views by sites and applications.

•  Using the path selection feature, dynamically selects the best path based on application-aware, business intent-based policies and network availability.

•  Delivers improved visibility with end user monitoring for all optimized traffic, including optimized web and SaaS applications.

•  TCP port 9443 and 443 for HTTPS communication. SCC 9.0.0 and later use port 443 for the REST API SSL key exchange between the SCC and SteelHeads. After the certificate exchange is successful, an OCC channel is established between the SteelHead and the SCC on port 9443, there after the SCC uses port 9443 to communicate with the SteelHeads.

•  TCP port 22 for CLI communication.

•  If the network is public, UDP port 4500 for encryption services.

•  IPv6 Support - SCC 9.5 supports IPv6 on the SCC communication channel with SteelHead, appliance manageability (e.g., NTP servers, logging, hosts, DNS, Web/FTP proxy, email, and management interfaces) policy pages, and Interceptor Cluster pages (e.g., in-path rules and load-balancing).

•  Web Proxy Chaining -Most enterprise customers have an existing proxy or cloud web security server for caching or security services. The web proxy chaining feature provides interoperability with a transparent upstream proxy or an explicit proxy setting to provide a local cache to save bandwidth. This feature supports:

•  Web Proxy Reporting - A new web proxy report page is available for the web proxy feature. We provide these reports:

•  SCC Scaling - SCC 9.5 has an improved multithread statistical retrieval system and an enhanced appliance filter for managing up to 1500 appliances. Adhere to these guidelines for deployments with 1500 appliances:

•  Import Intermediate Certificate Authority (CA) Certificate to the SCC - The SCC CA can generate a self-signed certificate or it can use a certificate issued by another CA that trusts the SCC CA. To use the certificate signed by another CA, the SCC imports that certificate. A CA that uses the self-signed certificate is called the Root-CA; a CA that uses a certificate signed by the enterprise-root CA is called Intermediate-CA. Combining all these CA certificates with user certificates forms a chain that is called the certificate chain. SCC 9.5 includes the Trusted CA Store page where you can store certificates of CAs (e.g. Root-CA, Intermediate-CA, etc.) that are required to complete the certificate chain. You can also import end-user certificates and private keys that do not require a certificate chain in the Certificate Authority page of the SCC.

•  SSL CA Signing Service for Proxy Certificates - In customer deployments where there are multiple SteelHeads that need to communicate with each other over a secure channel, a proxy certificate is required for SSL optimization. Prior to 9.5 the SCC CA signing service could only sign peering certificates for SSL connections between SteelHeads. Some customers have challenges in getting proxy certificates signed by their security team in the timely matter. In 9.5 we extend the CA signing service for proxy certificate signing. This feature enables you to set up any proxy certificate signing service.

•  If you’re running SCC 8.6 or earlier, you must perform a multistep upgrade. For example:

•  Upgrading from RiOS 8.6.x or earlier to 9.0 or later doesn’t automatically migrate previous QoS rules to a new configuration. Version 9.0 and later provides a QoS migration wizard to assist you in migrating your QoS rules.

•  You can’t migrate previous path selection rules from SCC 8.6.x or earlier to 9.0 or later.

•  If you mix RiOS software versions in your network, the releases might not fully support certain features (for example, QoS) and you can’t take full advantage of the 9.0 and later features that aren’t part of the prior software versions.

•  When upgrading large deployments (that is, more than1000 appliances) be aware that the initial upgrade may take several hours.