If you got a new computer system recently then it probably is using UEFI bios and it didn’t come with Windows installation media or a product license activation key. What gives?

Manufacturers are now embedding the activation key in the UEFI BIOS. You can retrieve the key by running this command from within a Windows powershell session:

wmic path softwarelicensingservice get oa3xoriginalproductkey

I moved my hard drive to a new Dell OEM PC (new motherboard/chassis/etc.) recently and had to activate windows 10 again once I was up and running. The activation kept failing. I found this out and went to the activation window, hit the “Change key” option and then ran the above command and pulled the key out of UEFI Bios on the new system and it worked without a problem. I had to change the key in my Windows 10 install to match the key stored in the UEFI Bios on the system. Thankfully my Windows 10 install from my old system was the “Pro” SKU and that is what the Dell workstation originally came pre-loaded with.

Easy!

Reference:
https://community.spiceworks.com/how_to/125321-pull-windows-key-from-uefi-bios

This will (hopefully) be brief…

Here is the Scenario:

  • You have deployed Office365
  • You have an on-prem Domain Controller (hopefully more than one!)
  • You are using Azure AD Connect 1.1 or greater, (which is installed on one of your domain controllers)
  • You create or manage user accounts using your on-prem domain controllers
  • Whenever you create a new user or make a change in AD you have to wait around (up to 30 minutes) for Office365 to reflect the change

In previous version of AAD Connect there was a Windows Scheduled task that would periodically sync AD data to Office365.

In later/latest versions of the tool there is now a scheduling engine that is part of the tool which is set to do a “delta” sync (only updates/changes) every 30 minutes.

When you are working though you might not want to wait around 30 minutes.
(more…)

If you use linux and have never come across this statement (or just realized this in the course of working with the OS), then let me be the first to tell you this critical truth…

Everything is a bloody file.”

While this holistic statement isn’t quite 100% true, it’s close enough that if you adopt it as your life verse and it becomes your “modus operandi” for working in Linux, you will go farther faster.

It is so ubiquitous there is a wikipedia page devoted to it.

This opens up some novel concepts… for example, because everything is represented by a file, it means almost anything can be easily scripted… hence part of the fun of Linux…

For all of you out there like me who came from the Windows world, “Everything is a File” can also be a keen point of frustration if no one has ever made this statement to you and explained some of the implications. I have done my service and made the statement, I will leave it up to you to research and discover the implications. Go forth and research and then come back and keep reading.

Now, I am going to move on and start my first article in the new “Everything is a File” series in which I am going to attempt to tackle some of the most common files found on Debian Linux variants and explain their usage. To kick things off, I am going to document a file that I have to look up commonly; FSTAB. (the whole point of my blog is to create a place that I can just search my own notes rather than Googling (and re-Googling 6 months later) for other peoples’ notes)
(more…)

I had that moment happen to me this past week… I knew it was coming but, like so many of you I said to myself “I probably have a few more months before it’s an issue”… Yep, my hard drive software warned me of impending doom on one of my data drives. I ignored it. Then a few days ago I heard that short squealing whine of death and Windows then informed me that my hard drive had no partitions and was empty of data…

That’s a bad day… especially when you realize that you may have some important documents and pictures of one of your children shortly after they were born (that aren’t kept anywhere else) that are now gone forever…

But are they gone forever? In this case, the drive in question was a “not all that old” 2 TB “spinning rust” 7200 RPM SATA drive. If this were a newer SSD drive then perhaps the situation would be more dire, but on old magnetic disks those shiny spinning platters (typically) still hold all of your precious data, it’s just hard to get to.
(more…)

I had a recent requirement from one of our clients that took a little bit of tinkering to figure out… we will call our client Contoso LLC. and our project that we host for them we will call the “Cool Widget Project.”

We built a really neat widget of an application for Contoso to use and we are hosting it under a sub-domain of a domain we control. We needed to keep hosting it under this domain. However, our client, Contoso, wanted to hand out a link for their users to the new widget we built using an existing sub-domain from a domain they control. This was of course under their main domain, constosollc.com, and they already had existing users that came to the old version of the widget (built by another vendor) at widget.contosollc.com.

Our company was hosting the new widget app at widgetapp.appworks.net.

To further complicate things… our company appreciates security, likes fast DNS updates, and the app really benefits from using a CDN… so we are using Cloudflare to manage DNS for the appworks.net domain. Better yet, we also like the cloud, and this new widgetapp is actually an Azure Web App.

So there’s the situation…

We essentially need this to happen:

User visits widget.contosollc.com --> widgetapp.appworks.net.

Oh but this is Azure… so actually widgetapp.appworks.net is already a CNAME record and it actually points to widgetapp.azurewebsites.net. So it is this:

User visits widget.contosollc.com --> widgetapp.appworks.net --> widgetapp.azurewebsites.net.

To elaborate the above just a little bit more:

widget.contosollc.com (DNS from random provider) --> widgetapp.appworks.net (Cloudflare DNS, CNAME) --> widgetapp.azurewebsites.net (the DNS name provided by Azure for the application)

Simple right? Just get our client to create a CNAME record that points to widgetapp.appworks.net and move on with life… wrong…
(more…)