Search This Blog

Tuesday, June 24, 2025

 SCVMM Integrate VMWare vCenter or Hosts


To integrate VMware vCenter and ESXi hosts with SCVMM, you need to ensure specific network ports are open between:

  • SCVMM servervCenter Server
  • SCVMM serverESXi hosts

This is required for discovery, inventory, and V2V migrations.


Required Networking Ports for SCVMM → VMware

1. To vCenter Server

Protocol

Port

Purpose

HTTPS

443

vCenter API communication

HTTP

80

Optional – fallback redirect

TCP

902

File copy & remote console (used during V2V)

These are essential for adding vCenter to SCVMM, discovering VMs, and initiating migrations.


 2. To ESXi Hosts

Protocol

Port

Purpose

HTTPS

443

Direct access (if no vCenter)

TCP

902

VIX/V2V file transfer agent

TCP

903

(Optional) Remote console (VMRC)

SSH

22

(Optional) Troubleshooting only

During V2V migration, SCVMM connects to port 902 on the ESXi host to transfer disk files (VMDK) and convert them to VHDX.



 

SCVMM → Hyper-V

Make sure SCVMM also has the correct ports open to your Hyper-V hosts:

Protocol

Port

Purpose

WMI/DCOM

135, 49152–65535

Remote management

WinRM

5985 (HTTP), 5986 (HTTPS)

PowerShell remoting

SMB

445

File transfer during V2V

BITS

80/443

Background file transfer


Firewall and NAT Considerations

  • Open ports bi-directionally if SCVMM and vCenter/ESXi are in different VLANs or across firewalls.
  • If using NAT, port forwarding must preserve TCP 902 directly to the ESXi host being migrated.

 


 Hyper-V standalone hosts with non-shared storage and replication for failover


Overview

When using Hyper-V standalone hosts with non-shared storage and replication for failover, you’re implementing a cold or warm disaster recovery approach, not a live failover cluster. This model suits smaller environments or remote offices without SANs. Here are best practices to ensure reliability, efficiency, and recoverability:


Architecture Best Practices

1. Use Hyper-V Replica

  • Set up replication between two standalone hosts (primary and replica).
  • Enable planned failover (for maintenance) and unplanned failover (for disaster recovery).
  • Configure replica frequency based on your RPO needs (default: 5 minutes; also 30s and 15min available).
  • If needed, use extended replication to a tertiary site.

2. Avoid Using Internal Disks

  • Prefer dedicated physical disks (RAID-protected) or pass-through disks.
  • For better reliability and portability, use VHDX files on NTFS/ReFS volumes with Storage Spaces or similar redundancy.

3. Use Fixed or Dynamically Expanding Disks

  • Prefer fixed VHDX for high I/O workloads (more predictable performance).
  • Use dynamically expanding VHDX for low/moderate IOPS VMs to save space.

Reliability and Recovery Best Practices

4. Automate Replica Failover

  • Use PowerShell scripts to automate failover/failback.
  • Integrate with Hyper-V Replica Broker (optional with failover clustering; in your case, manual scripting and orchestration are key).

5. Test Failovers Regularly

  • Perform test failovers quarterly.
  • Validate replica VMs boot, function, and revert cleanly.

6. Application-Consistent Snapshots

  • If using VSS-aware apps (e.g., SQL, Exchange), enable application-consistent replication.
  • Ensure Integration Services are up to date inside each VM.

Networking Best Practices

7. Use Identical Virtual Switch Names

  • Match virtual switch names on both hosts to simplify VM replication and failover.
  • Use MAC address spoofing and DHCP reservations if needed.

8. Plan for DNS Updates

  • Automate or prepare scripts to update DNS records after failover.
  • Use short TTLs on DNS records to allow fast propagation.

Operational Practices

9. Isolate Replica Traffic

  • Use a dedicated NIC or VLAN for replication traffic to avoid contention with production workloads.
  • Throttle bandwidth if needed via QoS or replication configuration.

10. Monitor Replication Health

  • Monitor via Event Viewer, PowerShell, or System Center VMM.
  • Automate alerts for replication failures or extended queue times.

11. Backups Still Matter

  • Replication is not a replacement for backup. Use VSS-aware backups of VMs and store off-host.
  • Ensure replicated VMs are excluded from backup jobs to avoid conflicts.

Maintenance and Lifecycle

12. Keep Hosts Patched

  • Use Cluster-Aware Updating (CAU) if eventually clustering, or stagger manual updates.
  • Validate patch compatibility with Hyper-V and replication roles.

13. Document Recovery Procedures

  • Maintain a written/runbook-style DR plan, including:
    • Planned vs. unplanned failover procedures
    • Networking and DNS adjustments
    • Data consistency expectations

Tools You Can Use

  • PowerShell Cmdlets: Get-VMReplication, Start-VMFailover, Complete-VMFailover, etc.
  • SCVMM (optional): For orchestration and monitoring.
  • Storage Replica (if using Server Datacenter Edition): For block-level replication on top of Hyper-V Replica.

 


 

GPU Acceleration VDI Wide for Office

Group Policy (Preferred for Domain-wide Control)

Steps:                                         

  1. Download the Office ADMX templates from Microsoft:
    Office ADMX Download
  2. Import into your Group Policy Central Store or local GPMC.
  3. Create or edit a GPO and go to:

User Configuration >

Administrative Templates >

Microsoft Office [version, e.g. 2016/2019/365] >

Miscellaneous

  1. Enable the setting:
    • "Disable hardware graphics acceleration"Enabled

This applies to all Office apps (Word, Excel, Outlook, etc.)


Option 2: Registry Setting (Per User)

If you prefer a script or don’t have GPO access:

# Disables Office hardware acceleration for the current user

New-ItemProperty -Path "HKCU:\Software\Microsoft\Office\16.0\Common\Graphics" `

  -Name "DisableHardwareAcceleration" -PropertyType DWord -Value 1 -Force

Replace 16.0 with:

  • 16.0 = Office 2016, 2019, 365
  • 15.0 = Office 2013

FSLogix Profile Container (Persist the Registry Key)

If you're using FSLogix:

  • Ensure the HKCU\Software\Microsoft\Office\[version]\Common\Graphics key is included in your container (not excluded).
  • This ensures the setting persists across VDI sessions.

 VMWare SRM “Like” Options for SCVMM Hyper-V


Overview

In a Microsoft Hyper-V environment managed by System Center Virtual Machine Manager (SCVMM), there isn't a direct one-to-one equivalent of VMware Site Recovery Manager (SRM), but similar functionality can be achieved through a combination of Microsoft tools and features:

Comparable MS Integrated Solutions to VMware SRM in SCVMM/Hyper-V:


1. Azure Site Recovery (ASR)

  • Closest equivalent to SRM for Hyper-V/SCVMM environments.
  • Provides orchestration, automation, and replication for disaster recovery (DR) scenarios.
  • Supports planned failover, unplanned failover, and test failover, just like SRM.
  • Integrates with SCVMM to replicate VMs between on-premises sites or to Azure.
  • Supports Hyper-V clusters, CSVs, and SCVMM clouds.

2. SCVMM + Hyper-V Replica (Manual DR Orchestration)

  • Hyper-V Replica allows asynchronous VM replication between two Hyper-V hosts/sites.
  • Can be managed and monitored in SCVMM, but lacks the full orchestration and automation of SRM.
  • Requires manual scripting or orchestration (e.g., PowerShell, Orchestrator, or Azure Automation) for failover plans and testing.
  • Suitable for smaller environments or less complex DR requirements.

3. System Center Orchestrator

  • Can be used with SCVMM and Hyper-V Replica to build custom DR workflows.
  • Allows automation of failover sequences, dependency handling, IP address changes, etc.
  • Adds orchestration layer but still lacks the simplicity and GUI-driven DR planning of SRM.


 

Summary Comparison Table

Feature

VMware SRM

Azure Site Recovery (ASR)

Hyper-V Replica + SCVMM

DR Orchestration

Yes

Yes

No (manual/custom)

GUI Failover Planning

Yes

Yes

No

Test Failover

Yes

Yes

Manual

Replication Type

Array-based or vSphere

Host-based (Hyper-V or Azure)

Host-based (Hyper-V)

Integration with SCVMM

N/A

Yes

Yes

Automation/Customization

Yes

Yes

Yes (with Orchestrator)

Failback Support

Yes

Yes

Manual

 


 

Azure Site Recovery with SCVMM and Hyper-V – DR Architecture Guide

Scenario

Organization is managing an on-premises Hyper-V environment with SCVMM, and they  want automated disaster recovery between:

  • Two on-premises datacenters (Site A → Site B), or
  • On-premises to Azure (Site A → Azure region)

High-Level Architecture (On-Prem to Azure)

On-Premises Datacenter (Site A)
├── Hyper-V Hosts (Clustered or Standalone)
    └── Production VMs
├── System Center Virtual Machine Manager (SCVMM)
├── ASR Provider installed on SCVMM server
├── Configuration Server (or Azure Site Recovery Unified Setup)
    └── Handles replication, orchestration, monitoring
└── Internet or ExpressRoute connection to Azure
 
Azure Recovery Services Vault (in target Azure region)
├── Replica storage (Azure Storage)
├── Target virtual network
└── Automation and orchestration via ASR

Prerequisites

On-Premises:

  • SCVMM 2016 or later
  • Hyper-V 2016 or later
  • At least one Recovery Services Vault in Azure
  • An Azure subscription
  • Internet access (or ExpressRoute) from SCVMM & hosts to Azure
  • Optional: Active Directory sync or AAD DS for seamless identity post-failover

 

Agents/Software:

  • Install Azure Site Recovery Provider on SCVMM server
  • Register SCVMM with the Azure Recovery Services Vault
  • Install Mobility service on each Hyper-V VM (can be pushed via SCVMM or Config Server)

Deployment Steps

1. Create a Recovery Services Vault in Azure

  • Use Azure Portal > Recovery Services Vault > Create
  • Choose region (this is where replicated VMs will go)

2. Prepare SCVMM and Register with Vault

  • Download the ASR Provider from Azure Vault
  • Install it on the SCVMM server
  • Register SCVMM with the Vault using generated key

3. Configure Replication Settings

  • Define clouds, storage accounts, and target networks in Azure
  • Map on-prem VM networks → Azure VNet

4. Enable Replication for VMs

  • In SCVMM or Azure Portal, select VMs or VM groups
  • Define replication policy (RPO, retention, app-consistent snapshots)
  • ASR installs the Mobility agent if not present

5. Create Recovery Plans (like SRM runbooks)

  • Define failover groups (VM order, scripts, pause steps)
  • Set boot order, post-failover scripts, etc.

6. Test Failover

  • Run a test failover to isolated Azure network
  • Validate connectivity, application functionality

7. Plan Failover/Failback

  • Initiate planned/unplanned failover from Azure Portal
  • After restoration, failback can be automated or manual depending on configuration

 

Benefits vs SRM

Feature

Azure Site Recovery

VMware SRM

Cloud DR Target

Azure (built-in)

vSphere or cloud with add-ons

Built-in Monitoring

Yes (Azure Monitor, Log Analytics)

Yes (vCenter, SRM plugin)

Cost Model

Pay-as-you-go (DR as a service)

Licensing + infra cost

Scriptable Recovery Plans

Yes

Yes


Security Considerations

  • Ensure TLS 1.2+ on all servers
  • Monitor with Azure Security Center
  • Use RBAC to limit access to DR management
  • Enable MFA on all Azure operations

 

Zerto Option for SCVMM Hyper-V Clustering Environment

Zerto can be used instead of Azure Site Recovery (ASR) or VMware SRM, and it's actually a very popular alternative — particularly for environments that require:

  • Cross-hypervisor DR (e.g., Hyper-V ↔ VMware)
  • Simplified, low RPO/RTO replication
  • DR between on-prem datacenters, cloud, or hybrid
  • Continuous data protection (CDP) with journal-based recovery

Using Zerto with Hyper-V (SCVMM or Standalone)

Supported Environment

Zerto supports:

  • Hyper-V 2012 R2, 2016, 2019, 2022
  • SCVMM-managed or standalone Hyper-V
  • Replication between Hyper-V → Hyper-V, Hyper-V → VMware, or Hyper-V → Azure/AWS

Zerto installs Zerto Virtual Replication Appliances (VRAs) on each Hyper-V host and a Zerto Virtual Manager (ZVM), which integrates with SCVMM.


How Zerto Compares to SRM/ASR

Feature

Zerto

VMware SRM

Azure Site Recovery (ASR)

Hyper-V Support

Yes

No

Yes

Cross-hypervisor replication

Yes (e.g., Hyper-V → VMware)

No

No

RPO

Seconds (CDP)

Minutes (Snapshot based)

Minutes (depends on policy)

RTO

Minutes

Minutes

Minutes to hours

Orchestration

Yes (boot order, scripting)

Yes

Yes

Failover Testing

Yes (non-disruptive)

Yes

Yes

Journal-based rollback

Yes (seconds to 30 days)

No

Limited

Licensing

Zerto subscription or term

VMware SRM + vSphere Rep.

Azure pay-as-you-go


High-Level Zerto for Hyper-V Architecture

Site A (Primary Hyper-V)
├── Hyper-V Hosts with VRAs
├── SCVMM (optional)
└── Zerto Virtual Manager (ZVM)
     └── Manages VPGs, orchestration, journal, reporting
 
<-- Replication over WAN -->
 
Site B (Recovery Hyper-V, VMware, or Cloud)
├── Hyper-V Hosts with VRAs (or VMware or Azure/AWS)
└── ZVM Peer

Recovery Orchestration in Zerto

  • Create Virtual Protection Groups (VPGs) — similar to SRM protection groups
  • Set boot order, scripts, and IP reconfiguration
  • Built-in test failover, move, and failover buttons
  • Journal-based rollback: failover to any point in time (within journal window, e.g., 7 days)

Pros of Zerto for Hyper-V Environments

  • No snapshot impact – near real-time block-level replication
  • Cross-platform flexibility – even future migrations to/from VMware or cloud
  • Superior granularity for ransomware recovery (down to seconds)
  • Non-disruptive testing – run full DR test anytime

Considerations

  • Cost: Zerto is a third-party solution and may cost more than ASR (especially if you're already in Azure).
  • Licensing: Requires licensing per VM or host.
  • Infrastructure: Requires dedicated VRA and ZVM setup at both sites.

Bottom Line using Zerto

  • Cross-platform DR flexibility
  • RPOs of seconds
  • Granular recovery (journal-based)
  • Faster failover testing and orchestration than ASR
  • Cost Analysis needed fo budgets and long-term viability