Virtualization of your work servers is a necessary action, but the problem is when you do that, you basically put all your eggs in one basket. Let’s imagine that your Hyper-V host with several VMs on it requires rebooting. Well, in that case, you won’t be able to boot a specific VM until the host OS is restarted, and all VMs are booted. And there’s no guarantee they will be available after that! Now, that surely doesn’t sound too good. However, luckily there are ways to make this process less painful and more efficient.

While configuring Hyper-V host, you’ll have to be able to boot your VMs in a specific order. I gotta admit, even though it took me a while to figure out how to customize this process, I have some results for you.
Mind, even if your server OS isn’t prone to failure, it’ll still be wise to configure Hyper-V automatic start action for VMs. One way or another, someday, you’ll have to reboot your server. So, when such a reboot occurs, it would’ve been nice if you didn’t have to boot ever separate VM manually, don’t you think so?

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.