Flying Friday: the great Gulfstream migration

Y’all may have heard of a little thing called Hurricane Matthew (or, as the Weather Channel continually called it, to the great amusement of my son Matthew, “DEADLY HURRICANE MATTHEW.”) And you may have heard of Gulfstream, the wildly successful purveyor of extremely expensive and capable business jets. But did you know that, for a while, our own Huntsville International Airport hosted nearly a billion dollars worth of Gulfstream hardware?

See, Gulfstream is based in Savannah, Georgia. They have a large factory there, with a satellite facility at Brunswick where they do paint and interior work. With a category 4 hurricane headed their way, Gulfstream made the very wise decision to find another place to park their airplanes until the storm passed, and Huntsville won the toss. On October 6th, I was listening to LiveATC and noticed a few airplanes checking in to Huntsville Approach with callsigns of “Gulftest XXX.” Neat, I thought. These must be test or acceptance flights. Then I heard a few more. Then one of the controllers asked a pilot how many more flights to expect– the pilot nonchalantly replied “oh, 30 or so.” That led me to check FlightRadar24 and, sure enough, the migration was well underway. (Sadly I didn’t think to capture any screen shots).

Last Sunday I drove out to the airport to take a few pictures of the shiny goodness on the ramp. These are links to my Flickr stream, which has lots of other airplane pictures if you’re into that sort of thing:

I was out of town this past week, so I missed the return flight, but sadly they’re gone now. It was fun to see them here, as that’s probably the closest I’ll ever be to such expensive hardware.

Leave a comment

Filed under aviation

Vertical constraints and the Avidyne IFD540

When you file and fly an IFR flight plan, you’ll have an assigned altitude for every segment of the flight. You’re not permitted to deviate from this altitude without permission (except in emergencies); the altitude obviously has to be high enough so that you don’t hit anything on the ground, and it may be capped on top to keep you away from other aircraft, clear of military training airspace, and so on.  (There are several different varieties of minimum altitude that you might be assigned on a route, but that’s a distinction for another day.)

These altitude assignments can often be expressed as constraints. ATC might, for instance, say “N32706, descend pilot’s discretion 4000”, which means I’m cleared to go from whatever altitude I’m at down to 4000′ at whatever rate of descent I want. I’m still not cleared to descend below 4000′ though. And of course, there are lots of constraints on instrument approaches, where we’re commonly told to maintain an altitude between an upper and lower limit at different segments of approach.

It’s common for air traffic control to give pilots crossing restrictions, too. For example, airplanes flying into Norcal Approach’s airspace will often be told to cross KLIDE “at or above 12000”. If they’re flying the ILS 30L (an excerpt of which is shown below), they’ll be told to “cross KLIDE at or above 4000, reduce speed to 230 knots”. You can tell that there’s a restriction there because of the horizontal line under the altitude– an underline means “at or above”, an overline means “at or below,” and both together mean “at”.

Those horizontal lines are important

Those horizontal lines are important

An example I’m personally familiar with is that, when you fly into McCollum Field in north Atlanta from the west, the Atlanta Center controller will typically tell you to cross 35mi west of the airport at a specific altitude. In days of old, I’d just do this manually, which required a bit of math– “a standard 500 foot/minute descent at X airspeed means I need to start descending at Y minutes.” The IFD540 makes crossing restrictions really simple to track, but the interface for doing so is a little weird.

To specify a vertical constraint, you use the FMS page. The problem is that, by default, the FMS page shows the flight plan as a strip along the right edge of the screen, and you can’t see the fields necessary to enter the constraint. The example below (taken from Avidyne’s excellent Windows simulator) shows what I mean– you can see the flight plan in FMS view but, unless you know this One Simple Trick, you can’t put in crossing restrictions.


Tapping the “FPL” tab on the left edge of the flight plan data strip changes your view, though. In the expanded view, it’s easy to specify the distance and altitude you want, as you can see in this picture from the actual IFD540. ATC told me “cross CARAN at 5000” and so it was a trivial matter to specify a crossing distance of 0nm and an altitude of 5000 feet. I could just as easily have handled an instruction like “descend to 5000 5nm west of CARAN.”


As soon as I put the restriction in place and switched back to the map view, I could see a new “TOD” (top of descent) circle showing me where to start my descent. In addition, notice that CARAN is now bracketed by lines above and below its name– that’s because I specified I wanted to cross at 5000. If I had said “at or above” or “at or below,” the symbology would reflect that.


There’s also an audio alert which sounds just like a doorbell– so If you start a 500fpm descent when you hear the chime at the indicated TOD, you’ll arrive at the specified crossing point at the right altitude. This is a very handy feature, especially since you can set any combination of distance and altitude. Want to make sure you arrive right at pattern altitude when coming into an unfamiliar airport? Set a restriction for, say, 2nm on the approach side of the airport for pattern altitude and voila!

Leave a comment

Filed under aviation

Office 365 Exposed episode 6, from Las Vegas

Fresh on the episode we did at Microsoft Ignite this year, Tony and I thought it would be fun to do another short episode while we’re both in Vegas for IT/DevConnections… so we did. Topics include a spiffy new profanity filter (for Office 365 Groups, not Tony and me), the triumphant debut of Focused Inbox on desktop Outlook, and a touching closing segment where Tony mourns the loss of a favored gadget.

Leave a comment

Filed under Office 365, Podcasts

Training Tuesday: training with heart rate variability (HRV)

[For some reason this scheduled post didn’t post on Tuesday so I’m manually reposting it day late. Selah.]

Normally, I’m not a big podcast listener because I (thankfully) don’t spend much time in the car, and I find having people talking in the background while I work distracting. However, working on the Office 365 Exposed podcast with Tony has helped me see that lots of people do like them, and that I might be missing out, so I’ve expanded my listening a bit. When I found that my coaching team at Complete Human Performance had a podcast, I subscribed. The most recent episode was with Dr. Mike T. Nelson, and he was discussing something called HRV (heart rate variability). It was a fascinating topic so I want to try to summarize what I (think I) learned:

  • HRV refers to the variance in the amount of time between heartbeats (not your heart rate itself)
  • It’s calculated based on heart rate measurements, from an EKG or other methods.
  • The most commonly used scale gives you a rating from 1-100.
  • You want your HRV to be high. A low HRV is generally a bad sign, and may in some cases even indicate impending heart problems.
  • The trend of your HRV is a useful indicator of fatigue, stress, and so on.
  • People who have low HRV values after heart surgery tend to have worse outcomes

Tracking HRV is especially useful for endurance athletes because it gives you a data point showing the total amount of stress that your cardiovascular system has been under. Mike Nelson, in the podcast, said that you should think of HRV as reflecting the cost of everything you do. Exercise, diet, rest, job stress, and personal stress all add to this cost. Factoring all those in, and measuring your HRV daily, you should be able to intensify or ease your workouts to keep your day-to-day HRV in the desired range.

“You can measure HRV with an app,” he said, so I did– I paused the podcast, grabbed the iThlete app, read its instructions, and took a reading. Mid-50s.

Nelson went on to outline a number of strategies for adjusting training to take HRV data into account– you want to get the most effective training possible, while still not having a long-term negative impact on HRV. I’m not doing that yet because you need a solid baseline of data to see what your “normal” HRV is. Mine looks like it’s hovering around 60ish. I don’t know enough to know if that’s good, bad, or what considering my age and physical condition, and I don’t yet understand the relationship (if any) between my resting heart rate and my HRV. I’ll keep an eye on it for another month or so and then start considering, in consultation with my coaches, what, if anything, I should use it for besides another nerdy data point.



Filed under Fitness

Creating Exchange dynamic distribution groups with custom attributes

You learn something new every day… I guess that means I’m ahead of schedule for the day.

A coworker asked if there was a way to use PowerShell to create a dynamic distribution group using one of the AD customAttributeX values. I didn’t know the answer offhand (since I create new distribution groups about every 5 years), but a little binging turned up the documentation for New-DynamicDistributionGroup. Turns out that the ConditionalCustomAttributeN parameters will do what he wanted:

New-DynamicDistributionGroup -IncludedRecipients mailContacts -ConditionalCustomAttribute6 "PeopleToInclude"

It turns out that wasn’t what he really wanted– he wanted to create a dynamic DG to include objects where the custom attribute value was not set to a particular value. The ConditionalXXX switches can’t do that, so he had to use a RecipientFilter instead:

New-DynamicDistributionGroup -IncludedRecipients mailContacts -RecipientFilter {ExtensionCustomAttribute6 -ne "PeopleToExclude"}...

Leave a comment

Filed under Office 365, UC&C

Microsoft Exchange engineering and cloud-scale

The Exchange team (or at least Perry Clarke, its fearless leader) has been known to describe Exchange Online as “the gateway drug to the cloud.” But how did that come to pass?

This week at Ignite, I was lucky enough to have dinner with some folks from the Exchange product team and a very, very large customer where we discussed the various ways in which Exchange engineering has blazed a trail the rest of Microsoft’s server products have eventually followed. After a bracing Twitter discussion this afternoon with @swiftonsecurity and some of her other followers, I thought it would be fun to put together a partial list of some of the things we discussed to illustrate how the Exchange team has built a stairway to heaven, or an elevator to the cloud, or something like that.

Let’s start with PowerShell. Love it or hate it, it is here, so we all have to deal with it. In 2007, the idea that Exchange would be built on PS was both revolutionary and, to many, revolting, but it allowed Microsoft to do several important things (not all of which shipped in Exchange 2007, but all of which are critical to cloud operations):

  • Greatly improve testability, both for the developers themselves but also for administrators, who now got a suite of protocol and endpoint-related tests they could run as part of troubleshooting– critically important when you have to troubleshoot in a global network of data centers hosting tens of millions of mailboxes
  • Fully enable role-based access control, also critical for cloud deployments where customers want to control who can do what with their data
  • Finally decouple the presentation layer of the UI (EMC, EAC, etc) from business logic
  • Massively improve the tools for scripting, including enabling very large-scale bulk operations– an obvious requirement for a cloud-scale service

Requiring PowerShell was a bold move by the Exchange team but one which has both paid off hugely and one that’s been echoed by the Windows, SharePoint, SQL Server and Skype teams, all of whom depend on it for managing their own cloud services. (See also: the Microsoft Graph APIs.)

Then there’s storage performance. In ancient days, getting scale from Exchange pretty much required the use of SANs due to Exchange’s IO requirements. Now, thanks to the IOPS diet imposed by Exchange engineering, it doesn’t. Tony does his usual excellent job of summarizing the actual reductions. Summary: Exchange 2016 requires roughly 96% fewer IOPS than Exchange 2003 did. There have been a ton of storage performance improvements in Exchange’s sister products (notably SQL) but those have their own stories that I’m not competent to tell. The relentless drive to cut IOPS requirements was one of the biggest enablers for Exchange Online, since controlling storage provisioning costs is critical for any type of scaled cloud service.

Of course, data protection is critical too. Exchange moved from having a single monolithic database to one with separate property and MIME databases (Exchange 2000) then to having software-based database replication with clustering (Exchange 2007) to shared-nothing, fully-replicated active/passive database replication (Exchange 2010 and later). Keeping multiple separate database copies (including lagged copies) enables all sorts of DR and HA scenarios that previously had required SANs. The ability to reliably use cheap JBOD disks, which thanks to Moore’s Law have embiggened nicely during Exchange’s lifetime, has been a key enabler for Exchange Online.

Then there’s a bunch of other architectural changes and improvements that are really only interesting to Exchange nerds. For the latest example, I present “read from passive,” but there’s also all the stuff covered by the Preferred Architecture.

Oh, I almost forgot: managed availability gives ExO a fair degree of self-healing, although its behavior sometimes surprises on-prem admins who see it do things on their behalf unexpectedly.

Oh, and let’s not forget the conversion of all the Exchange codebase to managed code– that was an important accelerator for the move to the cloud, as well as serving as a lighthouse for other product groups with code of similar vintage.

There are more examples, I’m sure, but these should get the point across– there’s been a steady stream of architectural changes in the nearly 20 years since Exchange 4.0 shipped that have led directly to the capability, power, and reliability of Exchange Online– which really has been the gateway drug for getting Microsoft’s customers to Office 365.



Leave a comment

Filed under UC&C

Flying Friday: the time I lost the keys

Recently Matt and I went on a jaunt back to Ohio. We flew from KDCU to 1G0, with a quick bathroom stop en route, and that went really well. Our visit with friends in Perrysburg was splendid, and I got to run the Boy Scout Half Marathon as a bonus. The plan was then to fly from 1G0 to Cleveland for the Cleveland National Air Show, departing Sunday morning for a noon show start, then to fly home. That all went really well, and we flew to and landed at Cuyahoga County Airport (KCGF), where the line crew at Cleveland Jet Center promptly and courteously got us parked and fueled. We went to the air show and had a great time watching the Blue Angels. (I got some great pictures that I’ll post on Flickr, eventually.) Thanks to the Cleveland Police Department, we had a long, hot walk to the nearest area where an Uber driver could pick us up, but soon enough we were back at the airport, whereupon I discovered that I had lost the key. It was on a keyfob, which I would have thought would render it unlosable, but no.

A quick visit with the mechanics at the FBO revealed that they had a box full of keys for other people’s airplanes. Little-known true aviation fact: there are relatively few different key patterns for light aircraft, so one airplane’s key can often be used to open the door or start the ignition of another airplane from the same manufacturer. With a little trial and error, we found a Piper key that would turn the ignition switch.. but I still needed to get a replacement made. On Sunday afternoon.

The FBO folks equipped me with a Cadillac SRX and Matt and I went in search of a hardware store. We found a nearby Ace Hardware, screeched into the parking lot 2 minutes before closing time, and walked out 3 minutes later with two replacement keys. Once back at the airport, I was delighted to find that they also turned the ignition switch, so we packed up, started up, and took off, only about an hour behind schedule. That was actually a good thing, as we got to enjoy a gloriously starry and clear night on our way home (with a stop at LEX for cookies and diet Coke).

Thanks to Cleveland Jet Center for helping us not be stranded!

(and yes, I now have a couple of spare keys stashed in strategic places… just in case.)

Leave a comment

Filed under aviation