Not much to say, the live cast was awesome. And SpaceX landed the Center Core this time.
Windows XP is Finally Dead
It took 17 years, 7 months and 16 days to happen, but Windows XP and all of it’s variants are no longer supported by Microsoft. Windows Embedded POSReady 2009 is no longer supported as of today. This marks the end of the Windows NT 5.1 code base, which definitely makes it the oldest Windows version to have been actively supported by Microsoft. Technically, the other versions of Windows XP were not supported with Security Updates, but a registry hack allowed those patches to be installed.
Microsoft will be making changes to the encryption settings on Windows Update in July 2019 that removes the ability to install updates. So if you are still using Windows XP, for whatever reason, you have until then to perform any final updates.
Sorry, I Don’t Have a GitHub Page
I think that I have probably been interviewed a lot. In the past 10 years I have probably been interviewed at least 100 times for positions that I have applied for. This does not count the number of phone interviews that I have had or any screening calls with an HR person, I mean I have put on a suit and met with a prospective employer at least 100 times.
Does this mean that I am bad at interviewing? Not necessarily. Interviewing is definitely a skill and I would like to think that I have gotten fairly good at it over the years. Interviews go both ways, and if I don’t think I would be a good fit for a company I won’t go forward with working for them. I also reject companies if I don’t think they have good values or I don’t believe in their visions. I have upset many employers and recruiters by declining further interviews and offers because I did not like the company I was interviewing with. I have also found that I no longer get nervous like I used to during interviews right when I graduated from College, which has definitely helped me as I have progressed in my career.
Why am I even talking about this? In case you have been living under a rock, this thing called DevOps and Automation is a pretty big deal nowadays. The line between Developers, Systems Administrators and Network Administrators is being increasingly blurred, so it is not uncommon to be asked to do code deployments and support when it sort of isn’t something you should be doing. The rise of AWS and Azure have definitely made this more common as well. I have been asked multiple times if I had a GitHub page to show a prospective employer what I have worked on and I always have to tell them no. This has had mixed results and I have had an interviewer lose interest in me the second they hear this.
So why don’t I have a GitHub page? Like everything in life, it is complicated. First of all I am not a programmer, so I don’t really need it. But wait, just because I am not a programmer doesn’t mean I don’t have a use for GitHub. I have used tools like GitHub for storing scripts and network configuration files that I have developed at my workplaces. The problem is, I typically don’t script for fun, I do it for all of the reasons that a good administrator uses scripting for, pure laziness. I find this handy chart useful for this:
Since I typically develop all of my scripts and network configurations while working for an employer or while I am on a contract, that means that all of the scripts that I develop are the property of that company. I also don’t really have a home lab anymore, so it’s not like I spend my evenings working on that for fun. I can’t just take a script that I wrote or modified at a former company and throw it onto the Internet for everyone to see. That is a pretty big issue and in this case I would be doing a few things wrong, including theft of company property and potentially exposing confidential information on the internal workings of a company.
So that is why I don’t have a GitHub page, and probably never will. Unless I get a lot more free time and start some unknown project, I don’t see that changing. But like everything in life, things change, so who knows. I believe very strongly in Open Source technologies, so anything I ever develop would be Open Source from day one.
I have been doing some work lately on a new project, and I am going to follow up this post with the question, “Do you know what Network Automation is?”
World Backup Day 2019
World Backup Day takes place every year on March 31st, but it is never a bad time to talk about backups and why they should be important to you. Unfortunately for most people, backing up their data is a pretty major afterthought and most people never even think about it. Backups are easier to do than ever to do with technologies such as OneDrive, Google Drive and iCloud. The amount of effort that used to be required to backup your data has dropped considerably in the last few years. There is pretty much no excuse to not make sure your data is protected in 2019.
For a few years my backup routine would consist of multiple external hard drives (all encrypted) that I would leave at home and off-site somewhere. I would cycle these devices monthly in order to make sure my data was safe. As time went on this became a major hassle, but I still keep at least one physical copy readily available. Storing data online is safe and cheap, so it is definitely something that you should take advantage of.
Losing your personal files due to a hardware failure or through malware is one thing, but I have had to tell businesses in the past that they had lost years of data due to bad or incomplete backups. Remember, if you have not tested your backups, do not consider them to be backups.
I won’t say too much more about this, to learn more about this initiative you should take time to visit the World Backup Day website at http://www.worldbackupday.com.
SpaceX DM1 Flight
The SpaceX Demonstration Mission 1 Flight has successfully completed as of 8:45 EST on Friday March 8, 2019. There were no issues and this is the very successful first step towards the next flight (In-Flight Abort Test) that will take place in the next few weeks, using the same Dragon Capsule that completed the DM1 Mission. If nothing major comes up, the DM2 flight should occur in the Summer of 2019 with two Astronauts on board.
Everything went perfectly and the Astronauts on-board the ISS were having some fun with the Zero Gravity Indicator that SpaceX left in the Dragon Capsule:
I have been following the development of the Dragon Crew Capsule and all of the changes that SpaceX has put into the Falcon 9 rocket to get to this point. I’m also looking forward to the next Falcon Heavy launches and the Raptor hop tests this Spring. 2019 is definitely going to be an interesting year in Space Flight.
Most Common Mistakes in Active Directory
The Microsoft Services Secure Infrastructure Team recently published a very detailed three-part series on the most common mistakes that they have encountered in Active Directory deployments. It was a very informative series to go through, the links can be found below:
Part 1: Most Common Mistakes in Active Directory and Domain Services – Part 1
Part 2: Most Common Mistakes in Active Directory and Domain Services – Part 2
Part 3: Most Common Mistakes in Active Directory and Domain Services – Part 3
As someone who has worked in many Active Directory Environments (probably over 50 separate environments in 10 years) and as someone who has created and migrated multiple Active Environments, I have run into most of these issues before and I am probably guilty of creating some of these mistakes in the first place.
Again, I haven’t run into all of these issues myself, but these are the ones that I have encountered in various Active Directory environments and here are my thoughts and additional comments:
Mistake #1: Configuring Multiple Password Policies for Domain Users Using Group Policy
This is an easy mistake to make with Active Directory. Password policies are always applied to user accounts and are located in the User Configuration GPO, and in most cases most users confuse with these password policies when dealing with service accounts. Applying these types of polices to an OU that contains only Servers or Workstations is completely ineffective and a waste of time, and instead need to be applied to an OU containing user accounts. In my experience, I have learned that it is best to create at least three password policies for accounts, with these requirements:
- User Accounts – 8 Characters with low complexity options
- Administrator Accounts – 16 Characters with high complexity options
- Service Accounts – 24 Characters with high complexity options
There are third-party tools available that are able to prevent known passwords that are unsuitable and have previously been used, and those tools should always be used whenever possible.
Mistake #4: Keeping the Forest and Domain Functional Levels at a Lower Version
I have encountered many organizations who are staying at a much lower Forest and Domain functional level for absolutely no reason. I unfortunately remember having to spend a lot of time retrieving entries from Active Directory before they were “tombstoned”. This was when the Active Directory environment was perfectly able to support the ADDS Recycle Bin (introduced with Windows Server 2008 R2). I am afraid to say it, but if in 2019 and you are not up to Server 2008 R2 Active Directory Functional level at a minimum, you owe all errors and inconveniences to yourself.
Mistake #5: Use DNS as an Archive by Disabling DNS Scavenging
I have encountered several environments with this particular problem. For one, as an Administrator, you need to be managing all DNS entries for critical entries in your environment. Workstations, whether they be Laptops or Desktops, or mobile devices have no business being found in an Active Directory DNS Server months or years after they expire. This only creates issues down the line with newer service taking over existing IP addresses. This is a no brainer, and is absolutely essential. It is literally a checkbox to enable and should be enabled by default. DNS is the most common problem in an Active Directory environment, so by not managing even basic items like this, you are making your job much more difficult than it needs to be.
Mistake #7: Installing Additional Server Roles and Applications on a Domain Controller
I am a firm believer in using servers for dedicated roles only, especially in an environment with Virtualization. Obviously, this has not always been the case in Windows Server, especially back in the day when Windows Small Business Server was in wide deployment. It was very common to have a single server running multiple complex services such Active Directory, Exchange Server, SharePoint, SQL and IIS. On top of that, all of these services were probably running on a basic server with basic hardware specifications. Speaking from experience, peeling off these additional roles from these servers is an absolute nightmare, and the amount of time required to deal with this is considerable. As a contractor I am all in favour of this, but a business should avoid this it all costs whenever possible.
Mistake #8: Deploying Domain Controllers as a Windows Server With Desktop Experience
This is a tricky one to deal with. It is certainly possible to deploy a Windows Server using the Windows Server Core deployment option, but not all Windows features support this option. You can use RSAT tools to remotely manage a Windows Server, and Windows Admin Center to manage through a web interface, but it does not always work properly. For example, some options related to Driver specific network settings do not always work properly in Server Core and can create issues that are not easily corrected in a Windows Server Core deployment.
At the end of the day, not all Administrators are up to the task of managing a Windows Server without using a GUI. At the end of the day, it is 2019 and if you are not able to adapt to using a server without a GUI, then you are the problem.
Mistake #9: Use Subnets Without Mapping them to Active Directory sites
I have been burned a few times by this issue, and it only ever applies when you have an Active Directory deployment over multiple offices/datacenter. This causes issues with replication, DFS and logins, so it is absolutely imperative that Active Directory Servers is correctly mapped with Active Directory Sites and Services. There is nothing worse than having a user incorrectly accessing an Active Directory Server unnecessarily from a Datacenter on the other side of the country.
OpenSSH Client and OpenSSH Server on Windows
Introduction
One of the biggest and most welcome changes to the Windows 10 1809 update and in Windows Server 2019 was the addition of the OpenSSH Client and OpenSSH Server features. It is now incredibly easy to SSH into a Windows Workstation/Server using native tools that are now builtin to the Operating System. In the past this was only possible by using complicated tools and odd workarounds in order to get an SSH-like implementation to work correctly. You can also use the SSH commands right from the Windows command line (CMD, PowerShell), without needing third-party tools or odd commands. This is a very nice change that Microsoft has added, since it is much easier to remotely manage a Windows through the Command Line instead of the GUI, and having the ability to use the same tools on both Windows and Linux is a big advantage.
Note: I have only tested this on Windows 10 Pro for Workstations (Version 1809 Build 17763.253) and on Windows Server 2019 Standard.
Installation
Installing the OpenSSH Client and OpenSSH Server options can be done through either the Settings app or through the Command Line.
GUI Installation
To install through the GUI, go to Settings -> Apps -> Apps & Features -> Manage optional features -> Add a feature. You should see the two options in the list of available features that can be installed:
OpenSSH Client
OpenSSH Server
Highlight each option and click the Install button to install the feature. If the options are missing, then you are not on the latest version/patch level of Windows 10 or Windows Server 2019. A restart should not be necessary after adding these features, but the newly installed services will need to be started and configured to automatically start at boot.
Command Line Installation
To install through the Command Line, open an elevated PowerShell console in order to proceed. To confirm that you are able to install the OpenSSH Client and OpenSSH Server features, run the following command:
Get-WindowsCapability -Online | findstr OpenSSH
Name : OpenSSH.Client~~0.0.1.0
Name : OpenSSH.Server~~0.0.1.0
If those two options are present, run the following two commands to install the features:
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Like installing through the Settings app, a restart should not be necessary after adding these features. The newly installed services will need to be started and configured to automatically start at boot.
Services Start
In order to start using OpenSSH Server, the associated services will need to be started first. This can be done through either the Services MMC console or through the Command Line.
Services MMC Console
Open the Services MMC Console (Win + R, and type in services.mmc) and find the two Services that are related to OpenSSH Server:
OpenSSH Authentication Agent
OpenSSH Server
Right-click on each service and select Properties. Under Service Status, click the Start button to start the service. To configure the service to start automatically at boot, change the Startup Type drop-down menu to Automatic and click Apply.
Command Line Services
To start the OpenSSH Server services and enable them to run automatically, there are a few command that you will need to run. To do this, open an elevated PowerShell console and run the following commands to start the OpenSSH Server:
Start-Service sshd
Start-Service ssh-agent
To have these services start automatically at boot, there are two additional commands to run as well:
Set-Service sshd -StartupType Automatic
Set-Service ssh-agent -StartupType Automatic
After this has been completed, you should be able to connect to your Windows installation over SSH.
Using OpenSSH Client
The OpenSSH Client can be used exactly the same way as you would on any Linux/Unix host. It will work through the regular Command Line and in PowerShell:
PS C:> ssh.exe
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface]
[-b bind_address] [-c cipher_spec] [-D [bind_address:]port]
[-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J [user@]host[:port]] [-L address]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-Q query_option] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command]
Here is the same output from a Linux environment:
matthew@thinkpad / $ ssh
usage: ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char]
[-F configfile] [-I pkcs11] [-i identity_file]
[-J [user@]host[:port]] [-L address] [-l login_name] [-m mac_spec]
[-O ctl_cmd] [-o option] [-p port] [-Q query_option] [-R address]
[-S ctl_path] [-W host:port] [-w local_tun[:remote_tun]]
[user@]hostname [command]
I won’t go into the details on how to use any of these advanced options, there are very good tutorials on how to use the OpenSSH Client on other sites. The behaviour of OpenSSH Client on Windows should be almost exactly the same as on a Linux environment. So far I haven’t run into any issues with connectivity.
Connecting to OpenSSH Server
There is nothing special required to connect to a Windows host, it behaves exactly the same way as any other SSH host. There are a few different username formats that you can use:
user@windows-host (Local User Account)
user@domain.local@windows-host (Domain UPN)
domainuser@windows-host (Netbios)
One of the benefits is the ability to login with a Microsoft account if you are using that as your username. It is a bit unusual to see an email address used this way, but I am glad that Microsoft made sure that this functionality worked correctly:
user@outlook.com@windows-host
There is nothing more to OpenSSH Server, you can manage your Windows host from the command line once you are logged in. If you want to do any further customization or need some basic troubleshooting, there is additional information below.
Change the Default Shell
By default when you login to a Windows installation with SSH, it defaults to the regular Command Prompt (cmd.exe). I prefer PowerShell for everyday usage, and it is easy to switch to PowerShell once you login, but you can change the default shell to save yourself some time if you are going to be using this feature often.
This is done through the Registry Editor, which will run with Administrator privileges. You need to navigate to the following key:
ComputerHKEY_LOCAL_MACHINESOFTWAREOpenSSH
Create a new string called DefaultShell and give it the following value:
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe
Restart the OpenSSH Server Service and the next time that you login with SSH, you should automatically go to PowerShell. I have tried making this work with Bash, but it doesn’t seem to be supported yet.
If you do want to use Bash, just type in bash.exe to switch to it.
Additional Settings
There are a few customizations that you can do to the OpenSSH Server service if needed. Since this is a port of the OpenSSH Server, the customization is done in a very similar way. To begin, the directory where all of the associated executable files are found is in the C:WindowsSystem32OpenSSH directory:
The other important directory for OpenSSH Server is the C:ProgramDatassh folder, which contains the configuration files and log files.
OpenSSH Server options, such as changing the login banner and locking down security options are done in the C:ProgramDatasshsshd_config file.
Not all options can be used on a Windows host. For more information, you can refer to the official Wiki article on what options are supported:
https://github.com/PowerShell/Win32-OpenSSH/wiki/sshd_config
Troubleshooting
If you need to view the log file for OpenSSH Server, you need to make a quick change to the configuration file (C:ProgramDatasshsshd_config) to enable logging:
# Logging
#SyslogFacility AUTH
#LogLevel INFO
Make the following change:
# Logging
#SyslogFacility LOCAL0
#LogLevel INFO
You will need to restart the OpenSSH Server service in order to apply the change. Once the change has been made, the log file (sshd.log) can be found in the C:ProgramDatasshlogs directory.
Sources
https://blogs.technet.microsoft.com/askpfeplat/2018/10/29/ssh-on-windows-server-2019/
Ultima Thule Flyby
The New Horizons spacecraft successfully completed it’s flyby of Ultima Thule (2014 MU69) at 12:33am on January 1st 2019. So far there has not been a lot of information released due to the slow (but steady) retrieval of data from the spacecraft, but the initial images are amazing:
I have been following the New Horizons mission since it’s launch in January 2006, and it’s encounter with Pluto on July 14th 2015. I think it is absolutely incredible that it has accomplished everything that it has so far, and that it is able to send back images and scientific information from over 6 billion km away.
It is going to be an interesting year for space exploration and space launches in 2019, and I am very excited for all of it.
Additional Reading:
My Year in Review
2018 in General
When I decided that I actually wanted to start a dedicated website/blog earlier in 2018, I intended to use it as a way to showcase what I was working on and what I have accomplished overall. I find that I work through a lot of problems and I never share the solutions with people, which is one of the main reasons that I wanted to create this site. I also wanted to use this site as a way to show what I was interested in with subjects other than IT, which I ended up not doing (even though I had several ideas, I never posted anything). I ended up not posting as often as I wanted to, but that will be something that I intend to change in 2019.
Something not related to this site, but something that I did that is sort of related (I guess) in 2018 is that I have deleted all of my social media accounts. It was a bit of a pain at first, but I have deleted my Facebook, Instagram and Twitter accounts. I also stopped using WhatsApp entirely due to their ownership by Facebook. I will spend the next few months reviewing what other sites and services that I am using on a daily basis and see if I am going to stop using them as well. I have also gone through all of the permissions on my Google accounts and I have even started restricting my usage of Google services.
I have started using a VPN service for some purposes (I would prefer not to say which service I ended up going with, but there are a lot to choose from) and I have started using alternative search engines other than Google for my daily usage. I ended up setting DuckDuckGo as my default for all of my devices. I find that it doesn’t do as good of a job as Google in some cases and is better in others, but overall it is good enough for my needs.
2019 Goals
I definitely want to finish a lot of the things that I have been working on. I have a list of side projects that I have been working and I want to work on, and I want to get completed by this time next year. If not, I at least want to have gone through everything and see where I am with it and see if it is worth pursuing.
Professionally, I want to continue my work with my side company (Ten Fifteen Solutions) and make a few changes to it. I also want to update a few of my certifications and get a few new ones in 2019 if possible.
I am looking forward to 2019 and I am looking forward to using this site more often. On a side note, Gutenberg is fine, I have no idea what the big issue is.
VMware Workstation and Hyper-V
I recently ran into an issue with my ThinkPad while trying to run VMware Workstation 15.0 when I had the Hyper-V role installed on Windows 10 Pro 1809. Having VMware installed at the same time as having the Hyper-V role installed is not an issue, but it is not possible to run both of them at the same time.
By default, once the Hyper-V role is installed the ability to run another Virtualization solution on top of that is no longer possible. This is due to the way that Hyper-V manages the regular Windows Kernel and the way that it allocates resources and manages the hardware once it is loaded.
Obviously, removing the Hyper-V role when not using it is possible, but it would be very inconvenient to have to constantly install/remove roles just to use another Virtualization solution such as VMware. I have this same laptop setup to run VMware ESXi 6.5 on a different drive, but that requires me to effectively take the laptop offline while I run a Virtual Machine and I would prefer to use that drive for another Operating System (such as Linux).
An easy solution to this issue is to create a new boot entry that disables Hyper-V at startup and will allow the use of another Virtualization platform (VMware, VirtualBox, etc). This is done using the bcdedit (Boot Command Data Edit) command.
To do this, launch a Command Prompt as Administrator (PowerShell will not work). To see the existing boot entries run the bcdedit command:
C:\WINDOWS\system32>bcdedit
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume5
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
badmemoryaccess Yes
isolatedcontext Yes
default {current}
resumeobject {ada423f5-c6a2-11e8-ddea-34e12df125a5}
displayorder {current}
toolsdisplayorder {memdiag}
timeout 0
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {433e1f12-c6a3-11e8-bd65-ddac20a2be71}
displaymessageoverride Recovery
recoveryenabled Yes
badmemoryaccess Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {ada423f5-c6a2-11e8-ddea-34e12df125a5}
nx OptIn
bootmenupolicy Standard
hypervisorlaunchtype Auto
There is one command that needs to be run in order to duplicate the existing Windows 10 boot entry:
bcdedit /copy {current} /d "Windows 10 No Hyper-V"
The output of this command will look something like this:
The entry was successfully copied to {533a4d12-c6a3-11e8-bd65-ddac20a2be71}.
Take the identifier from the command that was executed (don’t use the one from above, it won’t work for you) and use it in the next command that will disable Hyper-V in that boot entry:
bcdedit /set {533a4d12-c6a3-11e8-bd65-ddac20a2be71} hypervisorlaunchtype off
Once the commands have been entered, the new boot entry should now show up in the list of boot entries:
C:\WINDOWS\system32>bcdedit
Windows Boot Manager
--------------------
identifier {bootmgr}
device partition=\Device\HarddiskVolume5
path \EFI\Microsoft\Boot\bootmgfw.efi
description Windows Boot Manager
locale en-US
inherit {globalsettings}
badmemoryaccess Yes
isolatedcontext Yes
default {current}
resumeobject {ada423f5-c6a2-11e8-ddea-34e12df125a5}
displayorder {current}
{533a4d12-c6a3-11e8-bd65-ddac20a2be71}
toolsdisplayorder {memdiag}
timeout 0
Windows Boot Loader
-------------------
identifier {current}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10
locale en-US
inherit {bootloadersettings}
recoverysequence {433e1f14-c6a3-11e8-bd65-bbac98a2da91}
displaymessageoverride Recovery
recoveryenabled Yes
badmemoryaccess Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {ada423f5-c6a2-11e8-ddea-34e12df125a5}
nx OptIn
bootmenupolicy Standard
hypervisorlaunchtype Auto
Windows Boot Loader
-------------------
identifier {533a4d12-c6a3-11e8-bd65-ddac20a2be71}
device partition=C:
path \WINDOWS\system32\winload.efi
description Windows 10 No Hyper-V
locale en-US
inherit {bootloadersettings}
recoverysequence {433e1f14-c6a3-11e8-bd65-ccac20a2be71}
displaymessageoverride Recovery
recoveryenabled Yes
badmemoryaccess Yes
isolatedcontext Yes
allowedinmemorysettings 0x15000075
osdevice partition=C:
systemroot \WINDOWS
resumeobject {add423f5-c6b2-33e8-dbea-34e12ab125a5}
nx OptIn
bootmenupolicy Standard
hypervisorlaunchtype Auto
For the Windows 10 with no Hyper-V enabled, the hypervisorlaunchtype value is set to Off which is exactly what was needed.
There are two ways to boot Windows 10 to this new option:
- Hold Shift and select Restart from the Start Menu. Hold the Shift key until the system restarts.
- Go to Settings, Update & Security, Recovery. Under Advanced Startup, click Restart now.
From the Option screen, choose the Use another operating system option:
The option to boot without Hyper-V should appear as an option:
If everything worked correctly then VMware Workstation should work correctly. Hyper-V should not work, and show an error like this:
To use Hyper-V again all that needs to be done is reboot the system. While it is inconvenient to need to reboot a system in order to use a different Virtualization solution, it is not entirely common to have to run multiple Virtualization solutions on a single system, so this is certainly better than nothing.
For more information, take a look at the Microsoft Documentation for the bcdedit command.
