Tag: Azure

It’s snowing here on New Year’s Eve 2017 as I sit here in Northern Virginia, reflecting on the multitude of things that crammed themselves into the past 364 days. Turning the lens to Rubrik, I thought about all the features, enhancements and team members we added this year, and I wanted to take a moment to highlight my favorites. I think they’re pretty spectacular, while also being merely a few peaks that crested this year’s clouds.

#1: Cloud Cluster for AWS and Azure (BrikOS 3.2)

Rubrik Cloud Cluster was the culmination of a dream. It is the feature that truly transformed vision into reality. Rubrik’s tagline is “Cloud Data Management”, but to me, it felt shallow…nominal when that was limited to cloud archive (“CloudOut”) for long-term retention. Cloud Cluster changed everything.

It brought the same beautiful software stack to a highly flexible cloud platform (two, in fact: AWS and Azure), made protection of cloud-native applications possible, cloud mobility real, and terrestrial-free ascendance tangible.

Like the AWS and Azure clouds in which it runs, Rubrik Cloud Cluster is a subscription-based model with a low entry threshold, granular scale-out expansion (1TB at a time), and lean resource design. Contrary to industry collateral, “cloud” isn’t free, so the architecture choices we make should be conservative in their approach. We can’t afford to just lift-and-shift our resource demands and expect customers to pay the price for that laziness. That’s just one of the reasons I like Rubrik Cloud Cluster.

#2: The Ranger Team (January ’17)

2017 was an year of immense growth across all teams in Rubrik, but one team in particular was born near the beginning. The Rangers. At least one New Hire Bootcamp misunderstood the name to mean Park Rangers which brought more than a few laughs and groans on our part (especially in light of the mountains, river, and font, Smokey the Bear-style, in the PowerPoint slide). The true alignment and tribute is to the Army Rangers.

The Ranger team members are the blasting caps to the dynamite of Rubrik’s API-first architecture. They unlock the incredible potential of a platform entirely exposed via RESTful APIs.

Customers and partners are all over the spectrum on their DevOps journeys, but most have initiatives at some level of the organization to eliminate repetitive processes, introduce self-service capabilities, and enable cloud mobility. Rangers leverage languages like Python, Ruby, and PowerShell* to streamline workflows, aggregate analytics, and tie Rubrik into other ecosystem products.

Here are just a few examples of Ranger projects in 2017:

(*with some internal debate as to whether this is actually a language… :)


We’re in the process of updating our load balancing platforms and are migrating several test/dev and backoffice applications from Kemp Virtual LoadMaster (VLM) load balancers to F5 BIG-IP Local Traffic Manager (LTM) virtual edition (VE). Wow…three abbreviations in the first sentence. Buckle up :).

One of the services that we migrated this week was the Azure Rights Management Server (RMS) Connector. If you’re here, you probably know what the Azure RMS connector is, but just in case, here’s the short definition from Microsoft:

The Microsoft Rights Management (RMS) connector lets you quickly enable existing on-premises servers to use their Information Rights Management (IRM) functionality with the cloud-based Microsoft Rights Management services.

This seemed like it would be a simple migration when I started, but I couldn’t get the health monitor to report the servers up. It was all green on Kemp, but not on F5, with all the same check parameters. I tried it in a browser (IE, Chrome and Firefox) and that puzzled me more. The only way to load the check page (https://<azurermsconnector_fqdn/_wmcs/certification/servercertification.asmx) was to authenticate with domain user credentials. Strange. It seems that the VLM, at least in v7.1-20b, was accepting a 401 as a healthy response. But that didn’t help with BIG-IP…

BIG-IP (F5) has a great CLI utility that helped verify that authentication was indeed the hold up on its health monitor. Using openssl s_client, I checked using the monitor parameters and received a 401 unauthorized error:

 <h2>401 - Unauthorized: Access is denied due to invalid credentials.</h2>
 <h3>You do not have permission to view this directory or page using the credentials that you supplied.</h3>

I tried putting some domain credentials into the username and password fields on the BIG-IP health monitor, but that only succeeded in locking out the account. Then my colleague came across something that pointed us to use the account UPN ([email protected]) and that did the trick. Here’s the step-by-step from start to finish:

 1. Create HTTPS Health Monitor (Local Traffic > Monitors > Create…)

Fields below are required or otherwise different from default values

  • Name: rms_conn_https (feel free to name it according to your format)
  • Description: HTTPS monitor for Rights Management Server Connector
  • Type: HTTPS
  • Parent Monitor: https
  • Send String: GET /_wmcs/certification/servercertification.asmx HTTP/1.1\nHost: rmsconnector.domain.com\n
    (make sure you change the “Host:” to the FQDN of your RMS connector)
  • Receive String: ServerCertificationWebService
  • User Name: [email protected] (replace with your domain user service account)
  • Password: <password of above account>


Microsoft Networking Technology