Apr 242018
 
DNS

At 5:00AM MST (April 24th, 2018) this morning, I noticed DNS (Domain Name Service) name resolution is failing on numerous internet domains. After further troubleshooting, I realized it’s the root servers that provide DNS that are failing to resolve these hosts.

Some users on providers that cache records may not immediately notice the issues as their ISP has cached records. Doing a search on Twitter confirms numerous people are reporting issues with DNS across numerous providers and ISPs, Google DNS Servers, and Amazon DNS Servers.

 

Update 6:22AM MST:

On my DNS server, I’m noticing the problematic domains that aren’t providing DNS records, are loading NS records that use awsdns-XX dns servers. This could show a problem with Amazon AWS DNS servers. I will continue to try to identify where the issues are.

Update 6:32AM MST:

I’ve noticed that Amazon AWS has since added a “Recent Event” on their service status page for “Amazon Route 53”: “5:19 AM PDT We are investigating reports of problems resolving some DNS records hosted on Route53 using the third party DNS resolvers 8.8.8.8 and 8.8.4.4 . DNS resolution using other third-party DNS resolvers or DNS resolution from within EC2 instances using the default EC2 resolvers are not affected at this time.”

Update 6:45AM MST:

It appears that there are issues with Amazon’s Route 53 DNS service which provides cloud based DNS services. Trying to view https://aws.amazon.com/route53/ results in page load errors.

Update 7:06AM MST:

Another update from Amazon on their service status page for “Amazon Route 53”: 5:49 AM PDT We have identified the cause for an elevation in DNS resolution errors using third party DNS resolvers 8.8.8.8 / 8.8.4.4 and are working towards resolution. DNS resolution using other third-party DNS resolvers or DNS resolution from within EC2 instances using the default EC2 resolvers continues to work normally.

Update 3:50PM MST:

It appears this was actually a malicious attack including DOS, a man in the middle attack, and an attempt to compromise users accounts. Information can be found at https://doublepulsar.com/hijack-of-amazons-internet-domain-service-used-to-reroute-web-traffic-for-two-hours-unnoticed-3a6f0dda6a6f (thanks Juk for this post), and https://www.bleepingcomputer.com/news/security/hacker-hijacks-dns-server-of-myetherwallet-to-steal-160-000/ .

Apr 232018
 

Ready to jump the gun and upgrade to vSphere 6.7? Hold on a moment…

You’ll remember some time ago VMware announced they are dropping support for vSphere vDP (vSphere Data Protection). If you’re running this in your environment, it will break when upgrading to vSphere 6.7.

A better idea would be to migrate over to a product like Veeam, however please note that as of this date, Veeam does not officially support vSphere 6.7. Support should be coming in the next major update.

Apr 172018
 

With the news of VMware vSphere 6.7 being released today, a lot of you are looking for the download links for the 6.7 download (including vSphere 6.7, ESXi 6.7, etc…). I couldn’t find it myself, but after doing some scouring through alternative URLs, I came across the link.

VMware vSphere 6.7 DownloadVMware vSphere 6.7 Download Link

Here’s the link: https://my.vmware.com/web/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/6_7

HPE Specific (HPE Customization for ESXi) Version 6.7 is available at: https://www.hpe.com/us/en/servers/hpe-esxi.html

Unfortunately the page is blank at the moment, however you can bet the download and product listing will be added shortly!

UPDATE 10:15AM MST: The Download link is now live!

More information on the release of vSphere 6.7 can be found here, here, here, here, here, and here.

An article on the upgrade can be found at: https://blogs.vmware.com/vsphere/2018/05/upgrading-vcenter-server-appliance-6-5-6-7.html

Happy Virtualizing!

Feb 222018
 
HPe MSA 2040 SAN

There’s a new and easier way to find the latest firmware for your HPE MSA SAN!

A new website setup by HPE allows you to find the latest firmware for your HPE MSA 2050/2052, MSA 1050, MSA 2040/2042/1040, and/or MSA P2000 G3. This site will include the last 3 generations of SANs in the MSA product line.

You can find the firmware download site at: https://hpe.com/storage/MSAFirmware

Hewlett Packard Enterprise was also nice enough for provide a brief video on how to navigate and use the page as well. Please see below:

Leave your feedback!

Jan 292018
 
Microsoft Azure AD Connect Agent Updater

I’m writing today to share about an experience I had hours ago, where the Microsoft Azure AD Connect software (specifically the Azure AD Connect Agent Updater) actually updated itself, and restarted the server it’s installed on, all during production hours.

Pretty serious stuff hey?

It all happened around 12:50PM (Mountain Time)… I received a notification that a service had been marked as failed on the particular server (notification from my monitoring/management system), and I went to investigate. I noticed that the server was actually gracefully restarted. After logging in, I came across these event logs.

Event ID 34004

Event ID 1074

Both Event ID 34004 and Event ID 1074 were logged, reporting both that it had downloaded an update, installed, and the installer initiated a restart.

I thought: no way should auto-updating be enabled, and I still can’t actually confirm it either. I found this article which explains of an automatic update feature:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-feature-automatic-upgrade

However, not only did I not meet the criteria of auto-update being enabled, but upon further investigation it was actually disabled by running the powershell command:

Get-ADSyncAutoUpgrade

As you can see below the command returned as “suspended”.

Get-ADSyncAutoUpgrade

After spending tons more time searching and not finding anything, I decided I’d just disable the service called “Microsoft Azure AD Connect Agent Updater”. In my environment it was running and set to “Automatic (Delayed)”, but I stopped the service and changed it to “Disabled”.

It’s not reflected in the picture below, but this is the service that was responsable for updating and restarting the server. Since I’ve stopped it, it appears everything is functioning correctly, except auto-updating.

Microsoft Azure AD Connect Agent Updater