Today I’m planning on telling you as much as I know about virtual machine replication function in the Hyper-V environment with the current version of Windows Server 2019 OS as an example.

It is the second part of my research on SQL Server Availability Groups (AG) and SQL Server Failover Cluster Instances (FCI) performance. Before, I measured SQL Server AG performance on Storage Spaces (https://www.starwindsoftware.com/blog/hyper-v/can-sql-server-failover-cluster-instance-run-s2d-twice-fast-sql-server-availability-groups-storage-spaces-part-1-studying-ag-performance/). Today, I study the performance of SQL Server FCI on S2D, trying to prove that this thing can run 2 times faster than SQL Server AG on Storage Spaces

As an admin, I’m fully aware that while working with the virtual infrastructures, plan A doesn’t always relay a guarantee, so you have to have plan B up your sleeve. Microsoft Hyper-V Replica inbuilt technology is a massive help in a lot of cases. If you want to find out more about why exactly this technology is a life-saver in the matters of Hyper-V disaster recovery, look it up here.

For any business person, unplanned service disruptions and data center outages are the worst nightmares. However, while a lot may perceive such thing as inevitable natural disasters, Microsoft offers two excellent replication options to support disaster recovery and business continuity strategies – Hyper-V Replica and Azure Site Recovery (ASR).

High availability of Hyper-V VMs can be achieved through various means, one of them being Hyper-V Replica. The way it works is creating and maintaining copies of especially important (business-wise) VMs in a secondary site such as, say, backup data center. This solution is fault-tolerant so that even a loss of the whole data center won’t reflect on your VMs. However, an option like this is far from perfect because, for one, how many enterprises can simply afford a secondary data center? What if there isn’t one, but fault tolerance is still required on the platform level?

As of today, there’s no doubt of virtualization being the most discussed and developed aspect in the modern IT sphere. Therefore, engineers nowadays face more and more tasks that require quite specific knowledge, and there’s no way to avoid that. Case in point: just lately, I had to transform a few Windows Server 2016 R2 bare-metal servers (one of them was the domain controller) into VMs. UEFI served as a boot sector for every single one of them, which, as you can guess, was another obstacle.

As you all know, I frequently visit a lot of cloud infrastructure discussion boards, almost as frequently as I see people out there wondering what would be the best way to create a cluster in the Azure portal or configure S2D (Storage Spaces Direct) storage. Therefore, this article will be dedicated to creating a cluster in Azure and configuring S2D on this cluster. I have to warn you that within the article, I’ll use resources that become available after free online registration.

Right before we get started, you’ll have to sign in to your Microsoft Azure account. If for some reason, you don’t have a subscription or just don’t want to use your working environment for experimenting, you can get a free account here.

Today, we’re going to talk about little tricks on automating one of the most routine duties of an AD admin, namely creating multiple user accounts. Literally, every single one admin sooner or later meets the necessity to develop and activate several user accounts. If it’s a one-time activity and you don’t need more than 10 accounts, you better stop right here. However, if you have a large domain at your responsibility, or just have to create multiple accounts too often, there are ways to make your life much more comfortable.

In our daily work, we do often face a choice between low cost or high reliability. Today, I want to establish whether the game is worth the candle when you want to cut your expenses on important things. The premise is that combining Hyper-V and DC roles on the same bare-metal server is a bad idea.

To begin with, all the suggestions and statements in this material are derived from the personal experience, which means they were tried and tested on practice not once and not even twice. Getting that much into detail is not as significant as delivering you the big picture, so I’m going to concentrate on the latter.

Creating of Windows domain has always been a rock on which admins split. There are ones who will vouch for GUI. The others are more prone to PowerShell use. What do I think? Well, PowerShell is a flexible and universal tool, unlike GUI. So, no wonder this article is dedicated to creating and configuring a domain on Windows Server 2016 via PowerShell exclusively. I want to establish whether it will be helpful in the automation of this whole process.

IT infrastructure security is a number one priority, whether it be bare-metal or virtual infrastructure. The matter of safety in a Hyper-V environment, in particular, is one of those things that require attention first and foremost. However, whereas the fundamental aspects of covering the question of protection are widely known, there are always tiny details nobody really pays any attention to. Even experienced IT administrators tend to pass them by. This article takes focus on such issues. Either in a highly virtualized environment or private cloud, every one of them can become crucial.
Admittedly, establishing security baselines in the Hyper-V environment is a sink-or-swim scenario. The primary user concern is the host operating system (OS) and network hardware: you simply cannot maintain security on a proper level with only one product active. The safety of the Hyper-V environment requires a complex set of measures, including but not limited to constant monitoring of services and equipment.
All your virtual machines (VMs) and resources are dependent on the hypervisor. If someone takes control of it, you can say goodbye to all your data. That is why Hyper-V security is essential. Check out potentially dangerous mistakes listed in this article while setting up and maintaining network hardware, host OS, and your Hyper-V environment so that it won’t be infected with ransomware.