AirPods: A Brief Review

I don’t listen to a ton of music. The only iPod I’ve ever owned was gotten for free due to an educational benefit that came with a MacBook purchase. It stayed plugged into my vehicle 24/7. Music on the go? Not really my thing. Furthermore, the wired EarPods these things are supposedly shaped like unequivocally will not stay in my ears, nor will most ear buds. So why did I buy these things again?

My first brush with the AirPods came in an Apple Store after they had been released, but were perpetually out of stock. I mentioned to the sales rep how the buds never stay in my ears, to which he replied that they actually are shaped a bit differently and stick in people’s ears better. I doubted that, but he had a demo pair in the back that I tried on – and – gosh darnit, they stayed in. Head-banging, jumping up and down and generally flailing like a fool, and they didn’t move. Well, OK then. Popping the lid and holding it near my phone popped up the pairing page instantly, and within seconds I was listening to a song on one of my Apple Music playlists. Ut oh, I was in impulse-buy territory. Did they have any in stock? “Sorry, not at the moment.” Wallet saved.

As with most things electronic, however, the scarcity of the things drove me to crave them. Eventually I tracked down a pair on Craigslist with a reasonable bit of markup, and now I’m a proud and happy owner of Apple’s latest bit of wearable tech.

The Good:

• Portability. This case is seriously small, and can easily be mistaken for a pack of dental floss. The built in battery in the case offers up somewhere around a day’s worth of charge, and it practically keeps your ‘buds topped off at all times. I’ve never before used my change pocket on any pair of jeans, but that’s the home for the AirPods case whenever I’m out and about.
• Connection Quality. I’m not sure how Apple manages it (likely the W1 chip), but I can have my iPhone downstairs, and walk all the way upstairs, through the master bedroom and into the bathroom, and not have the audio skip a beat. In my car, if I cover my phone in my pocket with my palm, the Bluetooth audio to the car stereo cuts out. This kind of range from a Bluetooth device is simply amazing.
• Smarts. Taking out one bud and having the music stop playing is a simple but totally pragmatic use case. Someone talking to you? Pop one bud out and have a conversation, and then pop it back in, and the audio starts back up.

The So-So:

• Fit. Yes, I said earlier that I couldn’t get the buds to fall out. In practice, they aren’t *that* snug. I realize this is subjective to the wearer, but for me, the AirPods are still the best-fitting ear buds I’ve ever worn. It could be mental, as I tend to check on them and push them back into my ears from time to time (especially my left ear), but I still am not 100% confident that they won’t fall out of my ears with general walking around. I originally planned to go cycling with them in, but I might end up sticking to my over-ear sports bugs for that dirty work. I plan on further testing with the AirPods on the elliptical in my garage to test the grip when I’m sweaty. Either way, there’s no worry about *losing* them; if one was to fall out, I’d certainly notice.
• “It Just Works.” Right, well, Apple and everyone else has been touting how easy it is to pair these things to your iCloud devices, and that rings true. But once they’re paired, the case / bud battery widget reporting is spotty at best. Sometimes it pops up when open, other times it doesn’t. Sometimes it’s instant, other times it takes multiple seconds. And sometimes they ding when I put them in my ears, and other times they’re silent. There’s certainly a magical quality about them when they work as advertised, but they still feel a tiny bit finnicky to me. Hoping software updates in the future can address this sort of behavior.

The Bad:

• Siri. She’s just horribly inaccurate. I won’t blame the AirPods for Siri, but the limited options for engaging her are pretty frustrating. You only have one gesture: a double tap on one of the earbuds. That gesture either toggles play/pause, or invokes Siri. Invoking Siri takes a few seconds, and then you’re at the mercy of her accuracy. No offline mode, either, if you want to leverage voice commands for simple music actions like skip a track, or pause, or turn the volume up. If you don’t have the Internet (such as on an airplane), you have to go rooting for your phone or Apple Watch. Word on the street is that Siri’s due for a major update pretty soon, but I’d rather she get more accurate prior to shoe-horning her into every application imaginable. Luckily, I’m not one to bark commands verbally, so I likely won’t have to bump into her too much. Still, with as much as Apple (and the IT word at large) is pushing AI and voice assistants, it would be nice to be in an ecosystem with one of the better assistants.

Overall, I’m very pleased with the AirPods. I’m more of a podcast listener on the go, and I wish my vehicle’s Bluetooth wasn’t so aggressive in basically ruining any BT experience it’s a part of by horning in on every BT action, but I can’t blame the AirPods for that. For truly wireless headphones, they’re decently priced as well, compared to the other options in this space.

Forward-Confirmed Reverse DNS: A Primer

If you are responsible for running a mail server at your organization, you absolutely must read this post and heed its advice: learn proper reverse DNS configuration!

Spam is a huge problem. For every technique there is to filter it out, there exists at least one way to get around said tactic. Anti-spam engines are subjective and carefully crafted messages can exploit them in order to get junk mail delivered. There is one dead simple, commonly used best practice that every single email administrator who wants his outgoing email to reach its target needs to implement: forward-confirmed reverse DNS (FCrDNS).

FCrDNS is important because it prevents others from spoofing your hosts. Most spam lies about where it’s coming from; if it claims to be from a reputable source, it can get around a lot of filters. FCrDNS prevents a huge chunk of this behavior. Only the true domain owner can make FCrDNS work correctly, and thus is an important tool in detecting email phishing scams. This is how it’s suppose to work. In this case, assume your email server’s internet IP address is 1.2.3.4:

1.2.3.4 — PTR Record —> hostname.example.com
hostname.example.com — A Record —> 1.2.3.4

I see a lot of situations where only the PTR record (the top line) is implemented. Some email administrators assume this will satisfy reverse DNS requirements; it doesn’t. If it was sufficient, a spammer could simply have his ISP create the PTR record, valid or otherwise. The second line is where the real magic happens, as the hostname returned on line one needs to map back to the mail server’s IP address. Since the valid sender is the only person who can control the domain (in this case, example.com), a proper FCrDNS query verifies that the mail comes from a legitimate sender.

The most frustrating part about this? It’s no big secret. This is a de-facto standard for email servers; if you don’t have proper FCrDNS, you can expect your emails to be blocked by a lot of anti-spam filters. Time Warner enforces this. Verizon enforces this. Countless others do. In fact, any anti-spam solution worth its salt is absolutely going to leverage this extremely effective technique to more efficiently combat spam and phishing. Additionally, it’s stupid easy to set up. You simply make sure that you have an A record that matches the PTR record for your mail server IP, that resolves to the IP address of said mail server. Here, there’s even a handy dandy website that you can punch your mail server’s IP into and it will do all the forward and reverse lookups and tell you if you’re proper:

Forward Confirmed Reverse DNS Testing Form

So if you’re an email server admin, take five seconds and click that link and check yourself. Your users will thank you for it.

VMware ESXi 5 and Drobo

I have a larger-scoped post coming up sometime soon detailing our new infrastructure setup leveraging ESXi 5, Drobo, Veeam, and other best of breed technologies, but for now, I thought I’d bring some (more) attention to a pairing that is growing in number: VMware and Drobo, specifically, ESXi 5 and the Drobo B1200i.

Drobo recently introduced the B1200i as an entry-level iSCSI SAN for the enterprise. At around $12,000 for 12TB of storage, you’re talking serious bang for your buck if value is at the top of your priorities list. It also rates very high in the idiot test. If you have these things spread all over the world (which we do), any set of hands can be instructed to just plug a new drive in where the red light is.

Drobo has some pretty decent docs for setting up your B1200i for ESXi 5. This document outlines the Drobo-sanctioned way of setting up your array for VMware iSCSI connectivity. However, a recent Drobo KB article adds some wrinkles, and B1200i owners will be keen to pay attention to the differences.

• Firmware updates. As of right now, the B1200i is at 1.0.2, and at a minimum, you “must” [official Drobo word] use 1.0.1 to run on VMware. When I started this project, I got it working with 1.0.0, but apparently the performance improvements are vast starting at the 1.0.1 level.
• Use a dedicated iSCSI VLAN for storage traffic. Kind of a duh point, but still worth mentioning. I enabled jumbo frames in my environment, from ESXi to the Cisco to the Drobo, but I don’t see any difference in general use, and haven’t done performance metric testing.
• Create multiple 1- or 2TB LUNs. This I don’t yet understand, and I plan on bringing it up with a Drobo support engineer. Maybe it has to do with the way Drobo protects and optimizes access to these specifically-sized LUNs across the platters.
• If possible, allocate one VM per LUN. Yuck! Right after they recommend at least a 1TB volume, they say, put no more than one VM in it! Yeah, my 40GB Domain Controller is going to be sitting all alone in that 1TB volume. Boo hiss to this. Now, with just a handful of VMs and a fully loaded Drobo, this is no problem capacity-wise. But I still plan on raising this issue with Drobo as well, if for nothing else other than better understanding what makes the Drobo tick.
• Set NMP (Native Multi-pathing) to Round Robin on all iSCSI LUNs. The first Drobo doc I linked to has you setting LUNs to MRU (Most Recently Used), so this is an important change.

One we roll more of these out, and I get some free time at the office (ha!), I plan on putting these B1200i’s through their paces with some load testing to get some real numbers on performance. For now, they serve up our (admittedly basic) apps admirably. VM Guest boot time and RDP logins seem to lag a bit, but once the systems are up they’re plenty snappy. Again, watch this post for updates as I plan to flesh out the areas where my understanding is lacking.

SnapManager for SQL and SMVI “Recent” Snapshot Naming Bug

NetApp pushes its SnapManager software as the answer for backing up Exchange (SME), SQL (SMSQL), Oracle, SharePoint, and VMware virtual infrastructure (SMVI). It’s not without its faults, however, and I came across a pretty nasty one when first implementing SMSQL with the objective of eventually sending these backups off to tape.

Coupled with the bug that I will get to soon, NetApp’s support team seems to have a communications problem. I’ve talked to various engineers on this, only to be told that this was the first they’ve heard of it. Anyway, here’s how the problem manifests itself:

When creating a backup using SMSQL, one of the backup options is naming convention. You can choose between generic (which appends a “_recent” suffix to the backup name) and a timestamp, which gives each backup a unique name based on the time it was taken. The logic in the generic choice is that you always know what your most recent backup’s name will be. Which is an absolute necessity when it comes to using NDMP as a means for backup; you need to know the exact path name in order to back it up to tape.

The problem exhibits itself when you run SMSQL in conjunction with SMVI – SMVI actually wraps the snapshot name in its own container. So while a SMSQL snapshot name *should* be something like “sqlsnap__servername__recent”, it ends up with this: “smvi__sqlsnap__servername__recent_20120213022637”. You can see that SMVI is prepending the SMSQL job with its own name, and appending the unique timestamp to the end, completely eliminating the purpose of the recent naming convention.

To work around this, I had to create a PowerShell script that NetBackup called when the backup job for that volume executes. The script greps the snapshot list for the “recent” string (since there is only one with that in there), renames it to it’s proper name, and then runs the NDMP backup. Once the backup is complete, it renames the backup back to its “improper” form. If you don’t rename it back, SMSQL will break as it loses track of its most recent backup.

All in all, a bit of a kludge, but the official word (?) out of NetApp is that this bug requires a re-write of the SMVI framework, so the current plan is to see that sometime after Q2-2012. We’ll see about that. For now, this solution works wonderfully.

Forefront TMG: Included SQL Express is Broken

Ah, Forefront TMG. Modern replacement to ISA Server 2006. 64-bit. Supported on Windows 2008. Able to import ISA exports in a single bound.

Except you WON’T INSTALL OUT OF THE BOX ON A CLEAN 2008 SERVER INSTALL.

We’re talking totally standard Windows 2008 R2 install. Patched up. Downloaded the ISO from the VLSC site, mounted it to the VM, ran setup. Installed prerequisites, no problem. When it gets to the step of installing additional software, however, things go wrong:

Microsoft SQL Express 2008 (logging instance) could not be installed. As a result, Forefront TMG installation cannot be completed.

Oops. I searched high and low for this error on the net. Technet turns up a few results but they don’t seem to be related, oddly enough. One post pointed me in the direction of allowing the logged in user debug rights, since SQL express seems to want to install itself with debug logging turned on. No dice, though. That wasn’t it.

In order to get TMG installed after its already failed (and thus installed the necessary prerequisites), pop the CD image in, and browse to the TPC folder. Run MS_FPC_Server.msi. This will shoehorn TMG onto your server.

Once you’ve got TMG installed, open it up, and select the Logs & Reports list item. To the far right, choose to Configure Firewall Logging and Configure Web Proxy Logging. Change your selection from the embedded SQL database to a local file destination, or a standalone SQL instance if you’re into that sort of thing. We don’t do any reporting on our Reverse Proxy traffic, so we have no need for a SQL server.

Now I can finally start to migrate my aging Windows 2003/ISA Server 2006 boxes over to some fresh new builds. Bingo.

Lync 2010 Mobility, Push Notifications, and Default SIP Domains

Installing Lync 2010 from scratch was definitely an experience in trial and error. The documentation is weak at best at directing you when it comes to choosing a SIP domain. I initially chose to deploy Lync with a default SIP domain of contoso.local. Our default email addresses are @contoso.com.

When word hit that Microsoft would soon be releasing Lync clients for mobile platforms, I scrambled to get our on-premesis install ready to go. What discouraged me about the documentation was that it wasn’t made readily apparent that in order to use the mobile clients, you need to have a publicly-resolvable SIP domain. You can’t sign in as user@contoso.local. Frustrating to make the switch mid-stream, after Lync has already been deployed company-wide.

After going through the docs, I finally thought I had Mobility configured properly. The last thing to get working was federation with Microsoft’s Lync Push gateway. I was getting a 504 timeout on the following command:

Test-CsFederatedPartner -TargetFqdn “<fqdn of Lync Edge server>” -domain “push.lync.com” -ProxyFqdn “sipfed.online.lync.com”

Thanks to this technet thread, I figured out what the last issue was. Since I started my Lync deployment with contoso.local as my SIP domain, it was still set as the default, even after I had switched all my users over to contoso.com. I ran the following command:

Set-CsSipDomain contoso.com -IsDefault $True

And my Test-CsFederatedPartner command was successful! Then it was a matter of waiting for Microsoft to get their push gateway up and running (really Microsoft? Couldn’t sort this out before you released the clients and save yourself a lot of trouble?), and Test-CsMcxPushNotification worked as well!

Thought this issue was important to point out, since I would assume that many Lync deployments were rolled out using local SIP domains and then had to change course along the way to satisfy external communication requirements.