Thursday January 21st, 2016 17:42 SMTPSEND.DNS. NonExistentDomain: the magical error of wonders

Sometime around 4 p.m. or so the other day, all of my incoming mail just stopped working. And oh, what a fantastical tale do I have to tell about why.

I’m looking at a 2010/2013 coexistence that’s just one step away from having 2010 removed (I’m just doing all the CUs to guard against the old 4.3.2 random error that came about after SP1). So, mail was passing through 2010 on its way to 2013 where all the databases live.

In setting up 2013, I got a pretty solid course on what exactly all those new receive connectors do and how important they are for the communication and trust between the two editions. That being the most likely cause of a communication failure between the two, it was easy to diagnose as not the problem.

Little more background: we had a DC go down a little while ago, and I had built it back up, 2 days before this problem came to being, as a new server. It wasn’t promoted, it didn’t have ADDS or DNS roles installed. No reason that should be a factor.

So, following the error directly, I manually entered the live, functioning DNS into the 2010 NICs, removing the secondary. Then I went to the host (2010 is a VM) and did the same.

No dice.

I went on looking for other causes, but in the end came back to DNS.

To correct this, I had to manually specify the NIC with the exclusive DNS settings within Exchange. You go to Server Config -> Hub Transport, then the properties of the server and the “Internal DNS Lookups” tab. From the drop-down, select the NIC – instead of all IPv4 – and it displays the available DNS servers on that NIC. So long as the list is right, you’re good.

Immediately, over 500 emails in the queue started flowing out.

How in the world Exchange managed to ignore the server NIC, ignore the host NIC, latch on to a DNS server that no longer existed, then fail to find 2013 even when it could resolve through ping and nslookup, I have no earthly clue.

But if you find yourself in a similar mess, give that a shot.

In: Computers, How ToNo Comments

Wednesday September 30th, 2015 12:34 It’s Teamviewer time [may His Noodly Appendage help me]


Keeping with the tradition of intentionally destroying its own user base, Logmein has decided to screw over my company by jacking up their prices. Again.

I can understand how annoying it was last January for personal users to suddenly get hit with a $99 charge for 2 lousy computers. At the same time, I can’t understand who would have been a Logmein user if they only had 2 computers to which they’d want to remotely connect. Even with no one home, there are 3 in my living room. That, my friends, means a $249 annual to stick with LMI.

To which I say:

So, with the prospect of no longer being able to use that account looming, I started working on alternatives.

The trouble being: ports.

Being old timey and liking things like VNC, I got really excited when I came across NoMachine. Nice GUI with tiled saved machine connections. Just throw in an IP, open up a custom port on the home router, NAT traffic to individual machines (everyone assigns static IPs at home, right?) click go, right?

The place where I happened to test from, however, wasn’t allowing those ports to talk to anything.

Logmein uses TCP on 443, so it’s allowed traffic for nearly every network on the planet. That = awesome.

It’s not really a remote connection, but a simple internet connection to a central broker that’s swapping the data and sending it along with no more fanfare that a basic secure web request.

Now, connecting to my media server or coffee-table laptop pretty much never qualifies as a need. But this is a computer thing, and my brain doesn’t work that way with computer things.

It was then that I learned TeamViewer uses an initial attempt on 5398. If that’s not available, it’ll go to – you guessed it – 443.

Crap. Really didn’t want that to be my best option.

My longstanding disdain for TeamViewer even made me consider opening up RDP to my house. Then I remembered I’m not insane

Initial testing seems to indicate that the Big Hate is no longer a thing – it used to force manual update on new versions, which broke all connections – but only time will tell if this thing drives me crazy enough to do something even more drastic.

In: Computers, How ToNo Comments

Monday September 7th, 2015 16:56 An easily-missed pitfall when testing upgraded Exchange

We’ve got one client going from 2010 to 2013 and, believe me, the irony that this is happening right next to the 2016 release has not been lost (though, by all accounts it’s basically 2013 with slightly different colors).

This is the kind of operation that needs to happen with Absolutely No Errors At All.

Naturally, that means going completely overboard on the testing to a point where Outlook is starting to look at me funny and may have snuck out during the night to see a lawyer about a restraining order.

In this particular scenario, we have the luxury of a separate public IP that’s been NATted to 2013’s internal. Don’t have to turn on CAS at all, which saves setup time for the testing.

So, I rewrote the hosts file on an internal computer and one of my laptops, so we could do both inside and outside tests. Few errors here and there, but nothing that couldn’t be cleaned up pretty easily.

Everything worked fine except Outlook just wouldn’t get the new server info from autodiscover on an existing internal mailbox. Manual entry: fine. New profile: fine. External: fine. People who were migrated would need manual profile recreation.

So, the only thing that wouldn’t work is the most important thing possible for a project that requires Absolutely No Errors at All.


It took me a few days of wondering how in the hell autodiscover could possibly be affected, only internally, by the presence of an existing Outlook profile. I mean, that’s the kind of thing that sends you into full-on hate-research mode because no matter what you look at, nothing is quite describing the exact same situation and all these semi-related things have absolutely no effect and COME ON this has to be done right or we might as well not do it at all.

Where the idea came from, I cannot recall. But, the oft-overlooked stepchild of the OS was our culprit:

Windows. Credential. Manager.

As the tester, multiple tests accounts that I used saved their creds in there, creating a situation in which there was always at least one set pointing to the old server.

One day, I will look up all the tiny details as to why such a thing even matters to Outlook, but it is not this day. On this day, I must warn the people.

Hopefully someone else is spared this pain. Good night, and good luck.

In: How ToNo Comments

Monday April 20th, 2015 12:51 In which we rewrite install options to make Office 2013 do our bidding


There are only so many computers I’ve put Office 2013 on. Makes sense. A lot of people have 2010, which works just fine, and the drastic interface change is pretty uncomfortable for less-technically-inclined users.

So today was the very first time that I ran into a situation where someone needed Office, but not Outlook.

And now to explain why the above picture applies:

Because you can’t do that.

I mean, I can do that. I know how to hand-edit xml files and work with the command line after going through several pages of reference material from TechNet. You (read: nearly everyone else on the planet) cannot.

For the tl;dr crowd: The only way to make this work is to use the Click-To-Run tool, command-line download a separate setup package, config an xml by hand, command-line the install run, all so you replace the check-box function they removed with “<ExcludeApp ID=”Outlook” />“.

I get that it’s par for the course that a software company wants you to use their software above all others. Doing this at the cost of making your software harder to use: really, really stupid.

Especially if you imbue that in someone who tells a whole lot of people what software they should be buying.

Edit: per the comment below, technically Student will do this natively, but, as you can see down there, it wasn’t so much an option at the time.

In: Computers, How To(2) Comments

Thursday January 8th, 2015 10:36 Distribute Java security and update settings the easy way

Java may be the most annoying possible program on this planet.


I recently needed to standardize the security across an entire network, and everywhere you go there are deployment tutorials and GPO rollouts, but I couldn’t find anything for a direct approach. Having read those, it looked like a good option to do this via login script.

Here it is, if for no other reason than, by next week, I’m going to forget exactly what I did.

The file can get you most of what you need with this list of options, but if you’re dealing with a web-based Java app that isn’t updated – as so many are – you also want to add the exception.sites file one level deeper in the Sun folder.

[stextbox id=”black” image=”null”]xcopy \\server\share\java\ %userprofile%\AppData\LocalLow\Sun\Java\Deployment\ /y
xcopy \\server\share\java\exception.sites %userprofile%\AppData\LocalLow\Sun\Java\Deployment\security\ /y
xcopy \\server\share\java\java.reg %userprofile%\Downloads\ /y
xcopy \\server\share\java\reg_edit.bat %userprofile%\Downloads\ /y
%userprofile%\Downloads\reg_edit.bat /y[/stextbox]

Now you’ve got to keep it from updating. I like to keep at least one browser at the same version across all machines. IE is the easiest, as it can be done with one DWORD – assuming you don’t already have policy in place for this. It also updates far less often, so getting everyone on a single version doesn’t have to be some huge job that has to get done all at once.

[stextbox id=”black” image=”null”][HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy]


[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\jucheck]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN]

The problem you run into here is that both regedit.exe and reg import won’t run with a remote file such that all the prompts are suppressed, particularly UAC. The third and fourth lines of that first .bat move java.reg and the reg_edit.bat to an easy directory (could be anywhere) and the last line runs this locally:

[stextbox id=”black” image=”null”]@echo off
set __COMPAT_LAYER=RunAsInvoker
regedit /s %userprofile%\Downloads\java.reg

Normally I would balk at all that moving and running, but the total file size here is under 5kb. Even on an old clunker, that won’t take more than 2 seconds. And if it takes that long, 2 seconds won’t be a statistically significant portion of normal boot time.

I tested and this is working for the latest builds as of today: IE11 and Java 8u25.


I ran into another machine that was 32-bit. Given that case, it’s a matter of updating the reg as such, to account for any others that might be around:

[stextbox id=”black” image=”null”] [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy]


[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\JavaSoft\Java Update\Policy\jucheck]


[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy\jucheck]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN]

In: Computers, How ToNo Comments


IT guy, dev, designer, writer.

Got a degree in print journalism from UF but history dealt some bad cards to that industry, so I moved back to an earlier love: the computer.

Was recently at ZMOS Networks, but am now the Senior IT Associate at the Edna McConnell Clark Foundation.

My name is moderately common, as are a couple screen names, so always look for the logo to make sure you're reading something with official Km approval.

You can get to me directly with kyle(@)