Virtualguru

2025-08-14T19:55:00.007-05:00

Hyper-V Failover Cluster Setup Prep for SCVMM Integration

Method of Procedure (MOP) for setting up a 2-node Hyper-V Failover Cluster with 2x10GB NICs in SET (Switch Embedded Teaming) for the VM Network, and 2x1GB NICs for Management.

MOP: Setting up a 2-Node Hyper-V Failover Cluster with SET for VM Network and 1G NICs for Management

1. Prerequisites:

· Two servers with Windows Server 2022 Datacenter.

· 4 Network Adapters:

o 2x10GB NICs for VM and Live Migration traffic.

o 2x1GB NICs for general management of the OS.

· Shared storage (for Cluster Shared Volumes or CSV) or a shared network location.

· Network infrastructure that supports VLAN tagging (optional but recommended for segregation).

· Administrative access to each Hyper-V host.

2. Install Hyper-V and Failover Clustering Features

a. Install Hyper-V Role

On each node, run the following PowerShell command to install the Hyper-V role and required management tools:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

b. Install Failover Clustering Feature

On each node, run the following PowerShell command to install the Failover Clustering feature:

Install-WindowsFeature -Name Failover-Clustering

c. Reboot the servers if prompted to complete the installation.

3. Configure Network Interfaces

a. Configure the Management Network (1GB NICs)

1. Assign IP Addresses to Management NICs on both nodes:

New-NetIPAddress -InterfaceAlias "Ethernet1" -IPAddress 192.168.10.100 -PrefixLength 24 -DefaultGateway 192.168.10.1

This IP address will be used for management and cluster communication.

2. Make sure the 1GB NICs are not part of the SET switch.

b. Configure the VM Network (10GB NICs)

1. You will teaming the 2x10GB NICs to create a single logical adapter that will be used for VM traffic. This will be done using Switch Embedded Teaming (SET).

4. Configure SET Switch for VM Network (2x10GB NICs)

a. Create SET Switch

On the Hyper-V host, run the following command to create a SET Switch using the 2x10GB NICs for VM Network:

New-VMSwitch -Name "VM-Switch" -NetAdapterName "Ethernet0", "Ethernet1" -AllowManagementOS $false

· -Name "VM-Switch": This creates a virtual switch named "VM-Switch".

· -NetAdapterName "Ethernet0", "Ethernet1": Combines Ethernet0 and Ethernet1 into a SET Switch.

· -AllowManagementOS $false: Ensures that only VMs use this virtual switch (not the host’s management OS).

b. Create the SET Team for Load Balancing and Failover

Now, create the SET team for the 2x10GB NICs to ensure load balancing and failover:

New-NetLbfoTeam -Name "SET-Team" -TeamMembers "Ethernet0", "Ethernet1" -TeamingMode SwitchIndependent -LoadBalancingAlgorithm TransportPorts

· -TeamingMode SwitchIndependent: Sets the teaming mode as Switch Independent, meaning the team does not require a specific switch configuration.

· -LoadBalancingAlgorithm TransportPorts: This will distribute traffic evenly across the NICs using the Transport Ports method.

c. Verify the Team Configuration

Use the following command to verify the team setup:

Get-NetLbfoTeam

This should show the SET-Team with both Ethernet0 and Ethernet1 combined.

5. Configure VLANs (Optional, but Recommended for Traffic Segmentation)

If you are using VLANs for traffic isolation, configure the appropriate VLAN IDs for each network (e.g., VM Network VLAN 10, Live Migration VLAN 20).

a. Assign VLAN to VM Network

For each VM Network Adapter, assign the VLAN ID:

Set-VMNetworkAdapterVlan -VMName "VM1" -VlanId 10 -AdapterName "Network Adapter"

· -VlanId 10: Assign VLAN ID 10 to the VM's network adapter.

· -VMName "VM1": Name of the virtual machine.

· -AdapterName "Network Adapter": The default network adapter name in the VM.

Repeat this for each VM you want to be on the VM Network (VLAN 10).

6. Create the Failover Cluster

a. Validate the Cluster Configuration

Run the Test-Cluster command to validate the cluster configuration:

Test-Cluster -Node "Server1", "Server2"

b. Create the Failover Cluster

Once the validation passes, create the failover cluster:

New-Cluster -Name "HyperV-Cluster" -Node "Server1", "Server2" -StaticAddress "192.168.10.100" -NoStorage

· -StaticAddress "192.168.10.100": Assign an IP address for the cluster.

· -NoStorage: We are not configuring shared storage in this step.

7. Configure Clustered Storage

a. Enable Cluster Shared Volumes (CSV)

To use Cluster Shared Volumes (CSV) for storing VMs:

Enable-ClusterStorageSpacesDirect

This command will configure shared storage for use by all nodes in the cluster. You can use iSCSI, SMB shares, or direct-attached storage for CSV.

b. Add VMs to Shared Storage

Ensure that the VMs are created on the shared storage (CSV) to allow migration between nodes.

8. Enable Live Migration

Initially this will be enabled for testing then setup a separate Live Migration switch once basic Live Migration functions are working

a. Configure Live Migration Settings

On each node, configure the Live Migration network:

Set-ClusterParameter -Name "LiveMigrationNetwork" -Value "VM-Switch"

This ensures Live Migration uses the VM-Switch virtual switch for its traffic.

b. Test Live Migration

To test Live Migration, run the following command to move a VM from Server1 to Server2:

Move-VM -Name "VM1" -DestinationHost "Server2"

Ensure that the migration happens smoothly and that the VM remains online.

c. Setup Live Migration Swtich on SET (Optional)

Using SET switch (with VLANs enabled) and Live Migration is already configured on the virtual switch, here's what you should do:

Ensure Live Migration is configured on the switch (no need to configure VLANs for each individual VM network adapter).
Set up the dedicated Live Migration virtual switch using SET switch:

Example:

New-VMSwitch -Name "LiveMigration-Switch" -NetAdapterName "Ethernet0", "Ethernet1" -AllowManagementOS $false

This switch is dedicated to Live Migration traffic.

Ensure Live Migration network is set correctly in the Failover Cluster:

Set-ClusterParameter -Name "LiveMigrationNetwork" -Value "LiveMigration-Switch"

9. Test Failover and High Availability

a. Simulate Failover

Simulate a failover by shutting down Server1 (one node) and verifying that the VM automatically moves to Server2:

Stop-ClusterNode -Name "Server1"

Ensure that the VM is up and running on Server2.

10. Final Validation

1. Check Cluster Health:

o Open Failover Cluster Manager and verify that the cluster shows as healthy.

o Ensure all nodes and shared volumes (CSV) are accessible.

2. Verify VM Availability:

o Confirm that VMs are properly configured, stored on shared storage, and accessible after a failover.

Summary Checklist:

1. Install Hyper-V and Failover Clustering on both nodes.

2. Configure SET Switch with 2x10GB NICs for VM Network.

3. Set up management network with 2x1GB NICs (isolated for management traffic).

4. Assign VLANs for VM Network, Live Migration, and Management Network.

5. Create and validate Failover Cluster and configure Cluster Shared Volumes (CSV).

6. Enable and configure Live Migration.

7. Test Failover and Live Migration to ensure high availability.

8. Final Validation of the cluster health and VM availability.

Test Plan for 2-Server Hyper-V Failover Cluster

Objective:

To validate the installation and configuration of a 2-server Hyper-V Failover Cluster with SET switches, including network connectivity, live migration, and failover functionality.

Test Scope:

· Cluster Functionality

· Network Configuration (Management, VM, Live Migration Active)

· Virtual Machine High Availability and Live Migration

· Failover Testing

Test Environment:

· Cluster Nodes: Server 1 and Server 2

· Operating System: Windows Server 2022 Datacenter

· Clustered Resources: Hyper-V, Virtual Machines, Storage

· Networks Configured:

o Management Network

o VM Network

o Integrated or Independent Live Migration Network

Test Cases

1. Cluster Configuration Verification

Objective: Verify that the Hyper-V Failover Cluster is correctly configured and the cluster nodes are visible.

Test Steps:

1. Open Failover Cluster Manager.

2. Verify that Server1 and Server2 are listed as cluster nodes under the Nodes section.

3. Check the Clustered Roles section to ensure no errors are displayed.

4. Run the Validate a Configuration wizard:

o Launch PowerShell and run Test-Cluster to check the configuration for any issues.

Expected Results:

· Both nodes should appear without errors.

· The cluster should pass the validation tests with no critical errors.

2. Network Connectivity Check

Objective: Verify that the Management, VM, and Live Migration networks are functioning properly.

Test Steps:

1. Management Network:

o Ping 192.168.10.1 from both nodes.

o Check that you can access Cluster Shared Volumes (CSV) over this network.

2. VM Network:

o Check connectivity between VMs on both nodes by pinging each VM from one server to another.

3. Live Migration Network:

o Test connectivity between the two servers using the Live Migration IPs (e.g., 192.168.30.1).

Expected Results:

· Each node should successfully ping its respective IP address on the Management network.

· VMs on the VM Network should be able to communicate with each other.

· Live Migration IPs should be reachable from both nodes.

3. Virtual Machine Creation and Validation

Objective: Ensure that Virtual Machines (VMs) can be created, started, and run properly on the cluster.

Test Steps:

1. Create a new VM on Server 1 using Hyper-V Manager or PowerShell.

2. Start the VM on Server 1 and verify that it runs without issues.

3. Check that the VM is listed in the Failover Cluster Manager under Clustered Roles.

Expected Results:

· The VM should be successfully created and powered on.

· The VM should show as a clustered role in Failover Cluster Manager.

4. Live Migration of VM

Objective: Validate that Live Migration of VMs between nodes works without interruptions.

Test Steps:

1. Move a running VM from Server 1 to Server 2 using Hyper-V Manager or PowerShell:

Move-VM -Name "VM-Name" -DestinationHost "Server2"

2. Check that the VM successfully migrates without any errors.

3. Verify that the VM continues to run without issues after migration.

Expected Results:

· The VM should migrate without errors.

· The VM should remain operational after migration.

5. Failover Testing

Objective: Test the failover capability of the cluster by simulating a failure scenario and ensuring that the resources are automatically moved to the other node.

Test Steps:

1. Simulate a failure on Server 1 by shutting down or disconnecting the network interface.

2. Verify that the Failover Cluster automatically moves the VMs from Server 1 to Server 2 without downtime.

3. If Server 1 is brought back online, check that the VMs fail back to Server 1 automatically.

4. Ensure that the Failover Cluster Manager displays the correct status for the moved VMs.

Expected Results:

· When Server 1 fails, VMs should automatically move to Server 2.

· When Server 1 is restored, the VMs should fail back automatically.

· Failover should occur without manual intervention and minimal downtime.

6. Storage Failover Validation

Objective: Ensure that the shared storage (CSV) is functioning correctly and can be accessed by both nodes.

Test Steps:

1. Disconnect the storage from Server 1 (e.g., iSCSI or SMB share).

2. Check if Server 2 can access the storage and continue to serve the VMs.

3. Reconnect the storage to Server 1 and check that it can access the shared storage again.

Expected Results:

· Server 2 should be able to continue accessing the shared storage during the failure.

· Once the storage is reconnected to Server 1, it should be able to access the storage without issues.

7. Network Failover Testing

Objective: Verify that network failover occurs correctly between the Management, VM, and Live Migration networks.

Test Steps:

1. Disconnect the Management network on Server 1 and check if the management interface moves to Server 2.

2. Repeat this process for the VM Network and Live Migration Network, ensuring each network can failover to the other server without interrupting services.

Expected Results:

· Each network (Management, VM, Live Migration) should failover successfully to the other server.

· There should be minimal downtime during network failover, with the VM traffic unaffected.

Test Conclusion and Reporting

· Test Completion: All tests should be completed within a specific time frame (e.g., 2 hours).

· Issues Identified: Any issues encountered during the test should be logged, with troubleshooting steps recorded.

· Verification: Once all tests are successful, verify the cluster's overall health and performance through Failover Cluster Manager and other monitoring tools.

· Sign-off: After successful testing, sign off on the deployment and move on to the next stage (e.g., adding additional VMs, SCVMM integration, etc.).

This Test Plan ensures that all key components of the 2-node Hyper-V Failover Cluster are properly validated, including Live Migration, failover functionality, and network resilience. By performing these tests, you will ensure that your environment is fully operational and resilient.

2025-08-14T19:53:00.003-05:00

Citrix VPX Migration Advisory for Load Balancer Modernization

Method of Procedure

1. Pre-Migration Planning

Objective: Ensure all necessary preparations are in place before starting the migration.

1.1 Stakeholder Engagement

· Step 1: Schedule a meeting with VPX workload owners to discuss migration goals and expectations.

· Step 2: Identify critical applications and determine migration priorities.

· Step 3: Confirm migration windows, downtime expectations, and business continuity requirements.

· Step 4: Document stakeholder feedback and agreed-upon timelines.

1.2 Inventory and Configuration Review

· Step 1: Perform a complete audit of current SDX appliances (SDX-14020 and SDX-15030-25G).

· Step 2: Verify that the SDX-16240 appliances are properly racked, powered, and networked.

· Step 3: Document current network configurations, load balancing policies, and VPX instances on legacy SDX appliances.

· Step 4: Review the Flex Licensing setup for compatibility with SDX-16240.

1.3 Backup and Validation

· Step 1: Back up the current configurations of all VPX instances on SDX-14020 and SDX-15030-25G.

· Step 2: Verify the backup by performing a test restore to a lab environment.

· Step 3: Take snapshots of the current SDX appliances to preserve the state prior to migration.

1.4 Review Migration Strategy

· Step 1: Define the phased migration plan (2-3 weeks).

· Step 2: Schedule weekly progress check-ins with stakeholders to validate progress.

· Step 3: Ensure that rollback plans and contingency measures are in place.

2. Migration Execution

Objective: Migrate Citrix VPX instances to the new SDX-16240 appliances.

2.1 Set Up the New SDX-16240 Appliances

· Step 1: Confirm the physical setup of SDX-16240 appliances (racking, power, and network).

· Step 2: Configure High Availability (HA) mode on the SDX-16240 appliances using the Citrix ADC console.

· Step 3: Verify network connectivity, including VLAN configurations and routing on SDX-16240.

· Step 4: Ensure that Flex Licensing is enabled and configured on the SDX-16240 appliances.

2.2 Initial Migration (Pilot Phase)

· Step 1: Select 1-2 low-priority VPX instances for the pilot migration.

· Step 2: Deploy the selected VPX instances to the new SDX-16240 appliances.

· Step 3: Upgrade the VPX instances to the latest supported software version.

· Step 4: Validate Flex Licensing integration by verifying license application.

· Step 5: Test load balancing functionality for the migrated VPX instances (ensure correct traffic distribution).

· Step 6: Conduct application tests to verify that the migrated VPX instances perform as expected.

2.3 Full Migration (Batch Phases)

· Step 1: Migrate Phase 1 (5-7 VPX instances) from SDX-14020 and SDX-15030-25G appliances based on the established priority list.

· Step 2: For each VPX migration:

o Migrate the VPX instance to the SDX-16240.

o Upgrade to the latest supported software version.

o Verify the Flex Licensing is applied correctly.

o Apply relevant load balancing policies to each migrated instance.

· Step 3: Validate that migrated instances function correctly, ensuring no disruption to end-users.

· Step 4: Repeat for Phase 2 (migrate remaining VPX instances).

o Confirm that the HA configuration is properly maintained throughout all migrations.

2.4 Verification After Each Migration

· Step 1: Conduct post-migration checks on each VPX instance:

o Ensure network connectivity (ping, routing).

o Verify session stability and load balancing.

· Step 2: Stress-test the migrated VPX instances to ensure they can handle expected loads.

· Step 3: Conduct application validation for each migrated instance to ensure functionality.

3. Post-Migration Validation

Objective: Confirm all systems are functioning optimally after the migration.

3.1 Network and Application Testing

· Step 1: Test network performance across the SDX-16240 appliances.

o Ensure VLANs and routing configurations are correct.

o Verify network latency and throughput are within acceptable ranges.

· Step 2: Conduct end-to-end application testing to confirm migrated applications are working as expected.

o Validate that load balancing policies are being enforced correctly.

3.2 Licensing Validation

· Step 1: Confirm that Citrix Flex Licensing is fully functional and applied to the SDX-16240 appliances.

· Step 2: Verify that licenses are distributed appropriately across the VPX instances.

3.3 Performance Benchmarking

· Step 1: Compare performance metrics before and after migration (latency, throughput, resource utilization).

· Step 2: Conduct load testing to validate the system can handle the anticipated traffic volume.

4. Knowledge Transfer and Handover

Objective: Ensure the operational team can effectively manage the new SDX-16240 appliances.

4.1 Documentation

· Step 1: Provide detailed documentation of the new infrastructure (networking, VPX configurations, Flex Licensing, HA setup).

· Step 2: Include configuration files, migration logs, and troubleshooting steps.

4.2 Training

· Step 1: Provide training sessions for the operational team on managing SDX-16240 appliances.

o Topics should include load balancing, HA management, and Citrix Flex Licensing.

· Step 2: Include troubleshooting guidance in the training, such as session recovery and traffic rerouting.

4.3 Final Review

· Step 1: Conduct a post-migration review meeting to confirm all steps were followed and that objectives were met.

· Step 2: Address any issues or concerns raised during the migration and ensure they are resolved.

5. Risk Mitigation and Contingency Planning

Objective: Prepare for unforeseen issues and ensure a smooth rollback if necessary.

5.1 Rollback Plan

· Step 1: Define a rollback procedure to restore VPX instances to the SDX-14020/SDX-15030-25G appliances if needed.

· Step 2: Maintain the backup configurations from the pre-migration step to restore in case of critical failure.

5.2 Monitoring and Alerts

· Step 1: Set up monitoring tools to track appliance health, performance, and licensing status.

· Step 2: Configure alerts for critical issues like resource over-utilization, session drops, or license mismatches.

6. Finalization and Closure

Objective: Officially close the migration project and handover to operations.

6.1 Final Validation

· Step 1: Conduct a final round of validation to ensure all VPX instances are functional and fully migrated.

· Step 2: Ensure all services are stable and performing optimally.

6.2 Project Closure

· Step 1: Finalize all documentation and ensure operational teams are comfortable with the new setup.

· Step 2: Officially close the project and transition management responsibilities to the operations team.

References

https://www.citrix.com/products/citrix-adc/

https://docs.citrix.com/en-us/citrix-adc/current-release/deployment-guides.html

https://docs.citrix.com/en-us/citrix-adc/current-release/migrate/migration-vpx-to-sdx.html

https://docs.citrix.com/en-us/citrix-adc/current-release/high-availability.html

https://docs.citrix.com/en-us/citrix-adc/current-release/backup-and-restore.html

https://docs.citrix.com/en-us/citrix-adc/current-release/load-balancing.html

https://docs.citrix.com/en-us/citrix-adc/current-release/networking.html

2025-08-14T19:52:00.001-05:00

Microsoft DPM Upgrade & Operations Package

SECTION 1: Executive Summary

Environment:

Current DPM Configuration:

Windows Server 2016 Datacenter VM
System Center Data Protection Manager (DPM) 2016 – v5.1.378.0
SQL Server 2016 (local instance)
Synology NAS storage (iSCSI LUNs + CIFS shares)
Backing up ~35 enterprise servers

Goal:

Upgrade DPM from 2016 to 2019
Ensure compliance with current licensing requirements
Maintain backup continuity and performance

Recommendation Summary:

Proceed with a side-by-side upgrade for improved resiliency.
Purchase System Center 2019 Datacenter core licenses (and Windows Server 2019 licenses if deploying a new OS).
Reuse Synology storage or provision new LUNs for replica volumes.
Retain the old DPM server in read-only mode until legacy recovery points expire.

SECTION 2: Licensing & Procurement Guidance (Non-EA Customers)

How to Obtain Licenses:

Use CSP (Cloud Solution Provider) or Volume Licensing (Open Value) via certified Microsoft partners like Xerox.

Where to Obtain Licenses:

Microsoft Channel Resellers like Xerox, or directly through Microsoft’s partner portal.

Licenses Required:

Service	License Type
Windows Server 2019/2016	Windows Server 2019 Datacenter Edition (16-core minimum)
System Center DPM 2019	System Center 2019 Datacenter Edition (16-core minimum)
SQL Server for DPM	Bundled SQL Server Standard (local use only)

SECTION 3: Technical Upgrade Options

In-Place Upgrade:

Advantages:

Retains backup data and protection groups.
Lower cost.

Disadvantages:

Higher risk, limited rollback options.
Lower scalability path.

Side-by-Side Upgrade:

Advantages:

New server (Windows Server 2019 preferred).
Better testability and flexibility.
No risk of data loss during rollback.
Requires temporary dual licensing.

Disadvantages:

Higher initial cost, as two systems are running concurrently.

Factor	In-Place Upgrade	Side-by-Side Upgrade
Data Migration	No (retained)	Requires new replica data
Rollback Capability	Yes (must recreate backups)	No downtime or data loss in rollback scenario
Cost Efficiency	High	High (due to dual licensing)
Risk Profile	Moderate	Higher
Scalability Path	Limited	Better scalability options

SECTION 4: Network & Access Configuration

Ports Required for DPM Operations:

TCP 135 – WMI / RPC
TCP/UDP 5718, 5719 – DPM agent communication
TCP 445 – File share access (SMB)
TCP 1433 – SQL Server communication

Firewall Settings:

Enable WMI-In, RPC-In, File and Printer Sharing (SMB-In).
WMI Namespace: root\cimv2.

SECTION 5: Diagnostic Tools

Tool	Purpose
WMI Diagnosis Tool	Diagnose remote WMI connectivity
DPM Management Shell	PowerShell-based administration
Event Viewer (DPM Logs)	Monitor alerts and backup failures
Performance Monitor	Track disk throughput and bottlenecks
SQL Server Management Studio	Verify DPMDB health
Synology Resource Monitor	Validate NAS performance (DSM dashboard)

SECTION 6: Agent Deployment Account Setup

Create a domain service account (e.g., svc_dpmagent).
Grant local admin rights on all protected servers.
Add the account to the DPM Administrators group.
Ensure firewall allows remote RPC/WMI.
Use the account for pushing agents via DPM console.

SECTION 7: Backup Configuration

Group servers by role (e.g., SQL, File, VM).
Configure protection groups:

Define replica and recovery point volume sizes.
Set retention policy (e.g., 14 daily, 12 weekly, 6 monthly).
Enable consistency check schedules.

Verify disk capacity on Synology iSCSI LUNs.

SECTION 8: Backup Monitoring

Use DPM Console Monitoring tab.
Set up email notifications (SMTP required).
Enable Event Viewer alerting or SCOM integration.
Run Get-DPMBackupSummary for scripting reports.

SECTION 9: Basic Usage Guidance

Add agents from Management > Agents.
Protect workloads via Protection Groups wizard.
Run manual backups or restores as needed.
Test backup recovery monthly.
Track space and recovery point usage.

SECTION 10: Client Management

Maintain agent version compatibility post-upgrade.
Push updates using DPM console or PowerShell.
Monitor last successful backup per server.
Schedule consistency checks.
Use security groups for client access control.

Final Notes:

Keep the legacy server in read-only mode if needed for legal hold.
Document all upgrade activities in the change management system.
Validate Synology iSCSI configuration and retention plans.
Confirm that licensing aligns with total physical core counts.

2025-06-24T21:15:00.003-05:00

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 server ↔ vCenter Server
SCVMM server ↔ ESXi 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.

2025-06-24T21:12:00.009-05:00

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.

2025-06-24T21:10:00.004-05:00

GPU Acceleration VDI Wide for Office

Group Policy (Preferred for Domain-wide Control)

Steps:

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

User Configuration >

Administrative Templates >

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

Miscellaneous

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.

2025-06-24T21:08:00.005-05:00

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

2025-06-24T21:07:00.002-05:00

SCVMM Logical Switch Setup – Single and Dual NICs with Monitoring Capabilities

Step-by-Step: Creating a Logical Switch in SCVMM

1. Define Native Resources (Once Per Environment)

a. Create Virtual Network Adapters Port Profiles

Each vNIC (e.g., Management, VM, Live Migration) needs a Port Profile:

Fabric > Networking > Port Profiles > Virtual Network Adapter

Example Port Profiles:

Management – Medium weight (20%)
VM Network – High weight (40%)
Backup – Medium (20%)
vMotion – Low (10%)

Each profile includes:

Bandwidth settings (Minimum Bandwidth Weight)
QoS mode (Weight, Absolute, None)
Security settings (MAC spoofing, DHCP Guard, etc.)

b. Create Port Classifications

These are labels used to apply the profiles later on.

Fabric > Networking > Port Classifications

Create one per profile (e.g., "Management", "VM", "vMotion", "Backup")

Then map the Port Classification to the Port Profile.

2. Create Uplink Port Profile

Controls NIC teaming, Load balancing, VLAN trunking, and uplink mapping.

Fabric > Networking > Uplink Port Profiles

Set:

NIC Teaming mode: Static, LACP, or Switch Independent
Load balancing mode: Dynamic recommended
VLANs allowed: Trunk mode (specify allowed VLANs)

3. Create Logical Switch

Fabric > Networking > Logical Switches > Create Logical Switch

Configure:

Extensions (e.g., Microsoft NDIS)
Uplink Port Profile (created in previous step)
Associate Port Classifications
Enable Host Teaming (for 2 uplinks scenario)

Bandwidth Prioritization by Traffic Type

Use Minimum Bandwidth Weight in Port Profiles (QoS):

Traffic Type	Weight (%)	Notes
VM Traffic	40%	Default / dynamic traffic
Management	20%	Ensure host access remains
Backup	20%	Important but not time-critical
vMotion	10%	Only during migration events

These weights control how bandwidth is shared when contention occurs.
You can also define absolute minimums in newer SCVMM versions.

Traffic Separation Across 2 Uplinks (Active/Standby & Pinning)

SCVMM supports this using Network Sites + Logical Networks:

a. Define Logical Networks

Create multiple logical networks, one for each type of traffic (Mgmt, VM, vMotion, etc.), each with a unique VLAN.

b. Define Network Sites

In each Logical Network, create Network Sites that:

Specify uplink assignment
Pin VLANs/logical networks to specific uplinks (via host group)

c. Active/Standby Uplink Mapping

When defining the Uplink Port Profile, you can:

Assign specific uplinks to a VLAN or logical network
Use "Preferred" vs "Standby" NICs per traffic type

SCVMM doesn’t offer full traffic pinning in all teaming modes (e.g., in Switch Independent teaming, actual pinning depends on host-side NIC configuration).

Example: Uplink Behavior

Traffic	VLAN	Uplink 1	Uplink 2
Management	10	Active	Standby
vMotion	20	Standby	Active
VM Traffic	30	Active	Active
Backup	40	Active	Active

This logic is implemented by:

Network Sites per host group
Uplink Port Profile VLAN mapping
Port Profile + Classification on each vNIC

Summary

Task	Supported in SCVMM	Key Feature / Step
Create logical switch	✅	Port Profiles + Uplink Port Profile
Prioritize network bandwidth	✅	Minimum Bandwidth Weight (QoS)
Assign traffic to uplinks	✅ (with control)	Network Sites + Uplink Mapping
Pin workloads to NICs (e.g., Mgmt on NIC1)	✅ (via VLAN mapping)	Logical Network ↔ Uplink associations

Steps to Configure VLANs on a Logical Switch in SCVMM

1. Prerequisites

Physical switch ports are trunked (allowing tagged VLANs).
Hyper-V hosts are already added to SCVMM.
Uplink port profiles and port classifications are planned.

2. Create Uplink Port Profile

Go to Fabric > Logical Networks > Uplink Port Profiles
Click Create Uplink Port Profile
Assign a name (e.g., Trunk_Uplink)
Choose "Team" if you’ll use NIC teaming.
Under Networks, select the Logical Networks and associated VLANs (e.g., VLAN 10 for MGMT, 20 for VM, etc.)
Save

3. Create Logical Switch

Go to Fabric > Logical Switches > Create Logical Switch
Name it (e.g., Prod-Switch)
Choose:

Enable Uplink Mode = Team
Assign the Uplink Port Profile created earlier

Add Port Classifications (e.g., High Bandwidth, Standard, etc.)
Add the Virtual Port Profiles that map to those classifications

4. Create Logical Networks with VLANs

If not already done:

Go to Fabric > Networking > Logical Networks > Create Logical Network
Choose One Connected Network
Define Network Site(s) for host groups
Specify VLANs:

VLAN 10 – Management
VLAN 20 – VM traffic
VLAN 30 – Backup
etc.

Enable "Allow host access" if the host OS should use that network

5. Apply Logical Switch to Host

Go to Fabric > Hosts > Host > Properties
Under Virtual Switches, click New Virtual Switch
Select your Logical Switch
Choose adapters and map VLANs via the correct port classifications

Optional: Use PowerShell

Example powershell:

# Example: Create a logical network site with VLAN

$ln = Get-SCLogicalNetwork -Name "ProdNetwork"

New-SCLogicalNetworkDefinition -Name "Prod-VLAN20" -LogicalNetwork $ln -VLANID 20 -Subnet "192.168.20.0/24" -NetworkSite $site

Best Practices

Best Practice	Recommendation
Tag VLANs on SCVMM	Let SCVMM handle tagging—switchports stay trunked
Use consistent classification names	Helps templates and automation
Document VLAN-to-traffic mapping	Avoid misrouting and troubleshooting issues
Validate NIC Teaming/LLDP	Especially on converged networks

Monitoring Networking Traffic with SCVMM

Monitoring network traffic in SCVMM (System Center Virtual Machine Manager) helps you analyze bandwidth usage per VM, virtual NIC, or virtual switch—useful for troubleshooting, capacity planning, and ensuring SLAs.

Here’s how to monitor network traffic in SCVMM:

1. SCVMM Console (Basic Monitoring)

Steps:

Open SCVMM Console.
Go to VMs and Services.
Select a VM or Host.
In the bottom pane, go to the Performance tab.
If integrated with SCOM, you will see:

Network In (Bytes/sec)
Network Out (Bytes/sec)
Total Throughput
Historical charts

SCOM (Operations Manager) is required for detailed network monitoring and history.

2. SCVMM + SCOM Integration (Recommended for Full Metrics)

With SCVMM-SCOM integration, you get:

VM NIC throughput (in/out)
Hyper-V virtual switch monitoring
Network usage trends over time
Alerts and thresholds (e.g., high throughput)
Custom dashboards and reports

To set this up:

Import SCVMM management pack into SCOM.
Link SCVMM to SCOM (via SCVMM Settings > System Center Settings > Operations Manager Server).
Enable performance data collection rules.

3. PowerShell (Local on Hyper-V Host)

If you want live network stats without SCOM:

Get per-VM NIC traffic:

Get-VMNetworkAdapter -VMName "VM01" | Get-VMNetworkAdapterStatistics

Output includes:

BytesReceived
BytesSent
PacketsDropped

You can loop this over all VMs for bulk reporting.

4. Performance Monitor (PerfMon) on Hyper-V Host

Counters to Use:

Hyper-V Virtual Network Adapter(*)\Bytes/sec
Hyper-V Virtual Switch(*)\Bytes/sec

These can help track VM network traffic live and over time.

5. Windows Admin Center (WAC)

Another modern way to monitor VM network usage if SCVMM isn't connected to SCOM:

Go to WAC > Virtual Machines > Select VM
Navigate to Performance tab
View Network I/O over time

Summary Table

Method	Requires SCOM	Granularity	Notes
SCVMM Console	Optional	Low (real-time)	Enhanced with SCOM
SCVMM + SCOM	✅ Yes	High (historical)	Alerts, reports, per VM/VNIC
PowerShell (Host)	❌ No	Real-time	Simple and scriptable
PerfMon (Host)	❌ No	Real-time + logs	Use for long-term local logging
Windows Admin Center	❌ No	Medium	Nice UI, host-centric

PowerShell Scripts for Monitoring

PowerShell script to monitor network traffic (Bytes Sent / Bytes Received) for all VMs running on a Hyper-V host or across multiple hosts managed by SCVMM. I'll give you two versions:

Option 1: Run Directly on Hyper-V Host (No SCVMM / No SCOM)

This gives real-time stats per VM NIC:

# Get all running VMs on the local Hyper-V host

$vms = Get-VM | Where-Object { $_.State -eq 'Running' }

foreach ($vm in $vms) {

    $nics = Get-VMNetworkAdapter -VMName $vm.Name

    foreach ($nic in $nics) {

        $stats = Get-VMNetworkAdapterStatistics -VMNetworkAdapter $nic

        [PSCustomObject]@{

            VMName        = $vm.Name

            AdapterName   = $nic.Name

            BytesSent     = $stats.BytesSent

            BytesReceived = $stats.BytesReceived

You can schedule this or run it periodically to get current stats. The counters reset when the VM reboots.

Option 2: Run from SCVMM Server (For All VMs)

This version works in SCVMM PowerShell and queries all VMs managed by SCVMM, but it can’t get live byte counts without SCOM. However, it can get virtual NIC config and IP info.

# Load SCVMM module

Import-Module VirtualMachineManager

# Connect to SCVMM (skip if already connected)

# Get-SCVMMServer -ComputerName "SCVMM01"

# Get all VMs and their network adapters

$vms = Get-SCVirtualMachine | Where-Object { $_.Status -eq "Running" }

foreach ($vm in $vms) {

    $nics = Get-SCVirtualNetworkAdapter -VM $vm

    foreach ($nic in $nics) {

        [PSCustomObject]@{

            VMName       = $vm.Name

            NICName      = $nic.Name

            MACAddress   = $nic.MACAddress

            IPAddress    = $nic.IPAddresses -join ", "

            NetworkName  = $nic.VirtualNetwork.Name

This script gives a network overview but not live throughput (because SCVMM doesn't directly track bytes sent/received without SCOM).

2025-06-24T21:04:00.003-05:00

Citrix HDX Best Practices for End User Performance

Citrix HDX Overview

Citrix HDX (High Definition Experience) is a suite of technologies designed to optimize the user experience for Citrix Virtual Apps and Desktops. It includes features for graphics, multimedia, USB redirection, printing, and more. Proper configuration is critical for performance, especially in WAN/remote or resource-constrained environments.

Here's a breakdown of Citrix HDX configuration areas and best practices, updated for current deployments (e.g., Citrix DaaS on Windows Server 2019/2022):

Core HDX Configuration Areas

1. Display/Graphics

Preferred Codec: Use Adaptive Display v2 (H.264/H.265) for WAN users. This provides compression and lower bandwidth usage.
Use Video Codec for Compression: Enable and set to “For the entire screen” for low-bandwidth/high-latency environments.
Optimize for 3D apps: Use GPU-accelerated VMs (if available) with HDX 3D Pro.
Frame Rate: Set frame rate limit (30 or 60 FPS) based on use case (e.g., lower for office apps, higher for media apps).
Lossless Compression: Enable selectively; lossless = high quality, but increased bandwidth.

2. Multimedia (Audio/Video)

Audio Quality: Use “Medium” for balance. Only use “High” if needed for VoIP or media production.
Client Audio Redirection: Enabled by default. Restrict on low bandwidth links.
Windows Media Redirection: Enable for better performance with native media formats.
Browser Content Redirection (BCR): Offload YouTube and similar web content to the endpoint browser — useful for Chrome/Edge users.

3. USB and Peripheral Redirection

USB Redirection: Disable unless necessary. Use Generic USB for specific peripherals like signature pads.
Policy-Based Redirection: Use Citrix policies to allow/block specific devices via VID/PID.
Prefer Native Redirection: For printers, scanners, smart cards — use built-in redirection types instead of generic USB.

4. Printing

Use Universal Print Driver (UPD) when possible.
Session Printers: Use Citrix Policy or Group Policy Preferences, avoid logon scripts.
Print Server Placement: Prefer close proximity to session host (e.g., via DFS or local print server for WAN sites).
Auto-Creation Policy: Disable unless truly needed (especially in multi-session VDI or published apps).

5. Optimization Policies

Use Citrix Studio or Group Policy templates to manage HDX. Key policies:

Visual Display > Target Frame Rate
Multimedia > Multimedia Acceleration
Flash Redirection (if legacy apps)
HDX Adaptive Transport: Enable EDT (Enlightened Data Transport) — works over UDP for better performance.
Use TCP as fallback if EDT fails: Yes (default is now smart fallback).

6. Session Reliability and Transport

Enable Session Reliability: Keeps session open even during short-term network drops.
HDX Adaptive Transport: Always enabled unless specific compatibility issues.
WAN Optimization Tools: Use Citrix SD-WAN or WAN accelerators if operating over congested circuits.

Best Practices Summary

Area	Best Practice
Graphics	Enable H.264/H.265 Adaptive Display. Use GPUs if available.
Audio/Video	Medium audio quality, enable media and browser redirection.
Printing	Use Citrix UPD. Avoid client auto-created printers unless needed.
USB Devices	Redirect only necessary USB devices. Use native redirection types.
Policies	Manage through Citrix Studio or GPOs. Avoid conflicting settings.
Session Transport	Enable EDT with fallback to TCP. Ensure UDP ports are open.
Monitoring	Use Director and Citrix Analytics for user session quality tracking.
Latency Handling	Enable Adaptive Transport, Session Reliability, Frame Rate control.

Tools to Help

Citrix Director: Live session metrics and historical trends (latency, bandwidth, etc.).
Citrix HDX Monitor: Downloadable tool for deep inspection of HDX sessions.
Citrix Policy Modeling Wizard: Test policy inheritance and effective settings.
Citrix Insight Services (CIS): For health checks and environment diagnostics.

Checklist Example and Settings for HDX Environment Best Practices

Based upon the analysis of the user environment the following configuration details encompass GPO and Citrix Director Policies settings to optimize performance for Citrix HDX environment. These policies can be broken down to apply to specific groups of users via GPO Organization Units or Citrix Groupings per group and per user if required.

Citrix HDX Environment Profile

User Types (choose all that apply):

General Office / Task Workers
Call Center / VoIP Users
Power Users / Developers
Graphic Designers / CAD / 3D
Remote Workers on Home Networks

Endpoint Devices:

Windows PCs
Thin Clients
Macs
Chromebooks
Other: ___________

Session Type:

Multi-session VDI (e.g., Windows Server 2019/2022)
Single-session VDI (Windows 10/11)
Published Apps
Published Desktops

Do you use GPU acceleration (vGPU, passthrough, or AMD/NVIDIA hardware)?

Yes
No
Mixed

Citrix Environment:

Citrix DaaS (Cloud)
Citrix CVAD On-Prem
Version (if known): ___________

Network Conditions:

LAN (1 Gbps or better)
WAN (10–100 Mbps)
Remote / VPN (Variable)
High Latency / Congestion

Citrix HDX Policy Template (for Studio or GPO)

Graphics & Display

Setting	Value
Visual quality	Medium
Preferred color depth for simple graphics	16-bit
Use video codec for compression	For the entire screen
Use video codec when preferred	Enabled
Target Frame Rate	30 fps
Lossless	Disabled, unless needed for specific apps
Legacy graphics mode	Disabled
Framehawk	Disabled

Audio & Video

Setting	Value
Audio quality	Medium
Client audio redirection	Allowed
Enable Real-Time Audio Transport	Enabled
Video codec for compression	Use video codec when preferred
Windows Media Redirection	Enabled
Browser Content Redirection (BCR)	Enabled (if clients support it)
Flash Redirection	Disabled (deprecated)

Printing

Setting	Value
Auto-create client printers	Do not auto-create
Default printer	Set via Group Policy or session printer
Universal Print Driver usage	Use only if no driver found
Printer redirection	Allowed, limit via GPO

USB & Peripheral Redirection

Setting	Value
Generic USB redirection	Disabled by default
USB redirection rules	Whitelist specific VID/PIDs as needed
Client COM port, LPT port redirection	Disabled unless required
Client clipboard redirection	Allowed (bidirectional)
Drive mapping	Allowed (disable for call centers if needed)

Session Experience

Setting	Value
Session Reliability	Enabled
Idle timeout	Based on user type (e.g., 30 min for task workers)
Auto client reconnect	Enabled
Fast Reconnect	Enabled
Desktop Composition Redirection	Disabled
Dynamic keyboard layout sync	Enabled

HDX Adaptive Transport

Setting	Value
HDX Adaptive Transport	Preferred
Enlightened Data Transport (EDT)	Enabled
Fallback to TCP	Allowed
UDP Ports Open	Yes (1494, 2598, and Dynamic UDP range)

EPIC in Citrix – Best Practice Settings

General HDX Settings (Building on What You Already Have)

Setting	Recommendation	Notes
Visual Quality	Medium or Low	EPIC is not graphically intensive. Lower settings reduce bandwidth usage.
Use Video Codec for Compression	For Actively Changing Regions	Avoid full-screen video compression unless needed (e.g., embedded Citrix video redirection).
Target Frame Rate	24–30 fps	Sufficient for UI responsiveness; avoid higher FPS unless needed.
Lossless Compression	Disabled	Only enable if image fidelity is required (e.g., radiology apps).
Clipboard Redirection	Bidirectional or restricted to text	Prevent PHI leakage if needed.
Session Reliability	Enabled	EPIC sessions should be seamless through network glitches.
Adaptive Transport (EDT)	Enabled/Preferred	For WAN and VPN scenarios, EDT improves latency tolerance.

Printing and Session Behavior

Feature	Recommendation
Printer Mapping	Use Citrix Universal Print Server or session printers mapped by context (location-based printing)
Default Printer	Set via Group Policy, not user-controlled
Client Drive Mapping	Consider disabling to prevent data leakage
Roaming Profiles / FSLogix	Use FSLogix Profile Containers for consistent EPIC user state
EPIC Cache (Hyperspace)	Ensure cache location is redirected to a fast write location, not redirected folders

Display Settings and Performance

Feature	Recommendation
Display Protocol	Use Thinwire+ (not Framehawk)
Resolution	Prefer single-monitor or dual-monitor setups; avoid 4K or more than 2 monitors if not GPU-backed
Font Smoothing / ClearType	Can be enabled for readability, but may slightly increase bandwidth

Security Considerations

Smart Card Redirection: Enable if clinicians use badge-based access or e-prescribing.
USB Redirection: Block unless devices like signature pads or scanners are explicitly required.
Session Timeout: Consider shorter idle timeouts for compliance (e.g., 15–30 minutes).

EPIC Client Settings

Command-line flags for Hyperspace (-appserver, -cache, etc.) should be carefully reviewed with EPIC support.
Do not use roaming profiles to store EPIC cache. Redirect it to a local fast disk or ephemeral drive.

Group Policy Notes (if managing via AD)

Use the Citrix ADMX templates (matching your CVAD version) to apply these settings in Group Policy under:

Computer Configuration > Administrative Templates > Citrix Components > Citrix Receiver/Workspace/Desktop Agent

You can layer GPOs by Delivery Group (e.g., apply stricter limits for call center users or remote workers).

Comprehensive Summary of all Settings

Policy Name	Value
Visual quality	Medium
Preferred color depth for simple graphics	16-bit
Use video codec for compression	For the entire screen
Use video codec when preferred	Enabled
Target Frame Rate	30 fps
Lossless	Disabled
Legacy graphics mode	Disabled
Framehawk	Disabled
Audio quality	Medium
Client audio redirection	Allowed
Enable Real-Time Audio Transport	Enabled
Windows Media Redirection	Enabled
Browser Content Redirection (BCR)	Enabled
Flash Redirection	Disabled
Auto-create client printers	Do not auto-create
Default printer	Set via Group Policy or session printer
Universal Print Driver usage	Use only if no driver found
Printer redirection	Allowed
Generic USB redirection	Disabled by default
USB redirection rules	Whitelist specific VID/PIDs as needed
Client COM port, LPT port redirection	Disabled unless required
Client clipboard redirection	Allowed (bidirectional)
Drive mapping	Allowed
Session Reliability	Enabled
Idle timeout	30 min
Auto client reconnect	Enabled
Fast Reconnect	Enabled
Desktop Composition Redirection	Disabled
Dynamic keyboard layout sync	Enabled
HDX Adaptive Transport	Preferred
Enlightened Data Transport (EDT)	Enabled
Fallback to TCP	Allowed
UDP Ports Open	Yes (1494, 2598, and Dynamic UDP range)

Optional Profile-specific Adjustments

Call Center / VoIP Users

Prioritize Real-Time Audio Transport (UDP)
Disable clipboard and drive mapping
Consider using Citrix Optimization Pack for Microsoft Teams

Remote Users

Ensure Session Reliability is on
Limit video redirection unless performance is guaranteed
Consider turning off wallpaper and animations via policy

References

best-practices-for-optimizing-your-citrix-environment.pdf

Citrix Policy Settings – Carl Stalhood

Citrix Virtual Apps and Desktop - Graphics, HDX Optimization and Audio

2025-06-24T21:00:00.005-05:00

User Role and Permission Management in Hyper-V

Hyper-V natively has limited user-level permission control. You typically rely on:

1. Hyper-V Administrators Group

Users in this local group have full control over Hyper-V.
Add users via:

Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "DOMAIN\\user"

2. Authorization Manager (AzMan) (Deprecated)

Provided more granular control in older versions (2012 and earlier).
Not recommended today; replaced by SCVMM role-based access.

3. Constrained Delegation + PowerShell JEA

For advanced setups: grant users specific VM actions without full admin rights.

4. Granular NTFS & WMI Permissions

For storage paths or remote Hyper-V management.
Tedious and error-prone without SCVMM.

Bottom line: Hyper-V alone lacks true multi-tenant or delegated access control. For enterprise-grade delegation, use SCVMM.

Role-Based Access Control (RBAC) in SCVMM

SCVMM enables precise Role-Based Access Control with the following model:

Built-in SCVMM User Roles:

Role	Description
Administrator	Full control over all VMM features.
Fabric Administrator	Full access to infrastructure (hosts, storage, networks) but limited to assigned scope.
Tenant Administrator	Can manage tenant resources (VMs, templates, services) in their own scope.
Read-Only Administrator	View-only access to fabric.
Application Administrator	Deploy and manage services but not templates or hardware profiles.
VM Creator	Create, manage, and own VMs in assigned clouds/hosts.

Custom User Roles

You can create custom roles by:

Navigating to SCVMM Console → Settings → Security → User Roles
Click "Create User Role"
Assign:

Name
Members
Scope (clouds, host groups, library)
Quota (CPU, memory, storage limits)
Actions (what they’re allowed to do)

Scope & Quotas

You can restrict users to:

Specific host groups, VM templates, clouds, or library shares
Usage quotas like max VMs, CPU cores, RAM, disk, etc.

User Group Management

SCVMM supports Active Directory groups. Add users or groups as role members.
Example:

$role = Get-SCUserRole -Name "Dev Team Role"

Add-SCUserRoleMember -UserRole $role -Member "DOMAIN\\DevTeamGroup"

Summary

Feature	Hyper-V	SCVMM
Role-based access	❌ Limited	✅ Full RBAC
Multi-tenancy	❌	✅
Quota Management	❌	✅ CPU, RAM, storage
Granular Scoping	❌	✅ Host group, library, VM template
AD Integration	✅	✅

VM Grouping and Organization Options

SCVMM does not support a folder-based structure for organizing virtual machines (unlike VMware vCenter, which allows nested folders for VMs). However, SCVMM provides several alternative mechanisms to help you organize and manage VMs effectively:

Alternatives to Folder Structure in SCVMM

1. Custom Properties / Tags

You can define custom key-value pairs (like Team=Finance, Environment=Dev) and assign them to VMs.
These can be used to filter and group VMs in the SCVMM console.

Set-SCVirtualMachine -VM "MyVM01" -CustomProperty @{"Team" = "Finance"; "Environment" = "Dev"}

2. Clouds and Host Groups

Organize VMs by assigning them to different SCVMM clouds (logical resource pools) and host groups.
Useful for delegating access, resource management, and scoping.

3. VM Naming Conventions

Adopt a structured naming scheme like DEV-FIN-APP01 to simulate folder structure and make filtering easier.

4. Views and Filters in SCVMM Console

Use built-in filtering and group-by views (e.g., group by Owner, Status, Host Group, Custom Property).

5. Service Templates

Group VMs that function together (e.g., web, app, DB) using service templates in SCVMM. These are not folders, but allow logical grouping and lifecycle management.

Summary

Feature	Folder Equivalent?	Notes
VM folders (like vCenter)	❌ Not available	No folder hierarchy for VMs in SCVMM
Host Groups / Clouds	✅ Similar	Best for access and scope segmentation
Custom Properties / Tags	✅ Recommended	For filtering and dynamic grouping
Naming conventions	✅ Useful	Helps simulate folder organization
Views & Filters	✅ Flexible	Dynamic VM organization

How Tags Work in SCVMM

Tags are user-defined labels you can assign to:

VMs
Services
Templates
Clouds, etc.

Tags help with filtering, grouping, and organizing in the SCVMM console.

How to Pre-Create Tags

SCVMM doesn’t have a built-in GUI to manage a list of reusable tags. However, you can "pre-create" tags by assigning them to any object, which causes them to appear in the tag list. This can be done using PowerShell:

# This creates the tag by assigning it to a dummy VM or object

Set-SCVirtualMachine -VM "SomeVM" -Tag "Environment:Dev"

Once this tag exists, it becomes available in the SCVMM GUI.

Assign Multiple Tags Automatically to VMs

You can use PowerShell to assign multiple tags to one or more VMs in bulk:

Example: Assigning Tags to All VMs Matching a Pattern

Import-Module VirtualMachineManager

# Define tag set

$tagList = @("Environment:Dev", "Team:Finance", "App:SQL")

# Get target VMs

$vms = Get-SCVirtualMachine | Where-Object { $_.Name -like "DEV-*" }

foreach ($vm in $vms) {

foreach ($tag in $tagList) {

Set-SCVirtualMachine -VM $vm -Tag $tag

}

Tags use the format Key:Value (e.g., Environment:Prod), but SCVMM treats them as flat strings.

Optional: Remove and Replace Tags

# Remove all tags

Set-SCVirtualMachine -VM $vm -Tag @()

# Replace with new tags

Set-SCVirtualMachine -VM $vm -Tag @("Environment:Test", "Owner:JohnDoe")

Summary

Action	Supported?	Method
Pre-create reusable tags	✅	Assign to any object via PowerShell
Assign multiple tags to VMs	✅	PowerShell script (bulk or individual)
GUI tag assignment (multiple)	❌	GUI is one-at-a-time only
Automate tag logic	✅	PowerShell + VM filters (name, owner)

Monitor and Track User Information and Audits

SCVMM (System Center Virtual Machine Manager) doesn’t directly monitor user profiles (like Windows logins or FSLogix profiles) or provide detailed audit logs by default. However, it does offer basic auditing and role-based access logging related to SCVMM actions (e.g., who created/modified/deleted a VM).

To achieve full profile monitoring and auditing, you’ll need to combine SCVMM with other tools like SCOM, Windows Event Logs, or third-party auditing solutions.

What SCVMM Can Audit

1. SCVMM Role-Based Access Control (RBAC) Auditing

SCVMM logs all actions taken by users with SCVMM roles (Admins, Delegated Admins, etc.).

Viewable in:

Jobs workspace in SCVMM Console
SCVMM Database (dbo.tbl_VMMJob table)
PowerShell:

Get-SCJob | Where-Object { $_.UserName -ne $null } | Select-Object UserName, Status, StartTime, Description

This shows who did what, when (e.g., create/delete VM, change settings).

2. SCVMM Audit Logging via Event Viewer

SCVMM logs key events to:

Event Viewer > Applications and Services Logs > Microsoft > System Center Virtual Machine Manager > Admin

Example events:

Job completion
Access errors
Role assignments

You can forward these logs to a SIEM like Splunk, Azure Sentinel, or Log Analytics for auditing.

What SCVMM Does Not Audit Directly

Windows user profile changes (e.g., FSLogix, roaming, temp profiles)
File-level auditing or logon/logoff
GPO changes or registry auditing

To audit those, use:

Feature	Tool
User logon/logout	Windows Security Event Log
FSLogix profile events	Event Viewer (FSLogix logs)
Group Policy changes	Advanced Audit Policy + Event Log
File/Folder access	NTFS Auditing
Central auditing/logs	Microsoft Defender for Endpoint, Azure Sentinel, or SCOM

Centralize SCVMM + Windows Auditing (Hybrid Approach)

Use these tools together:

SCVMM: Logs user actions inside VMM (VM creation, resource change)
Windows Event Viewer: Logs profile, session, login, file access
SCOM or Azure Monitor: For centralized collection and alerting
Azure Log Analytics: For workspace queries across VMs and SCVMM

Optional: Enable Advanced Auditing on SCVMM Server or VM Hosts

Use this GPO path:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration

Enable policies like:

Audit Logon Events
Audit Account Logon Events
Audit Object Access
Audit Policy Change

Helps track user behavior beyond SCVMM itself.

PowerShell – View SCVMM User Access Logs

Get-SCJob | Where-Object { $_.Status -eq 'Completed' -and $_.UserName -ne $null } |

Select-Object UserName, StartTime, Description | Sort-Object StartTime -Descending

Summary

Capability	SCVMM Native	Needs Other Tools
Track VM creation/deletion/mods	✅ Yes	—
See who did what in SCVMM	✅ Yes	—
Logon/logoff tracking (users/VMs)	❌ No	Windows Event Log / SCOM
Profile tracking (e.g., FSLogix)	❌ No	FSLogix logs / Event Viewer
File/folder access auditing	❌ No	NTFS Audit / Defender
Alerting and dashboards	❌ No	Azure Sentinel, SCOM

SCVMM Overview for Multi-User Access and Controls

To allow an unlimited (or large) number of users to manage Hyper-V VMs simultaneously, you need centralized management that supports multi-user access, role delegation, and scalability. Native Hyper-V Manager is not designed for this—it's single-user focused and lacks granular access control.

Best Method: Use System Center Virtual Machine Manager (SCVMM) + Role-Based Access Control

Why SCVMM is Best for Multi-User Management:

Feature	SCVMM	Native Hyper-V
Multi-user access	✅ Yes	❌ Limited (no built-in RBAC)
Role-based permissions	✅ Yes (scoped delegation)	❌ No
Self-service portal	✅ With Azure Pack or WAP	❌ No
Centralized management	✅ Yes	❌ No
Scalability	✅ High	🚫 Not suitable for many users

How to Set It Up

1. Deploy SCVMM

Install System Center Virtual Machine Manager on a dedicated management server.

Add your Hyper-V hosts or clusters
Import VMs into the SCVMM inventory

2. Set Up Role-Based Access Control (RBAC)

SCVMM supports:

Administrator – Full access
Delegated Admin – Scoped to a host group
Read-Only Administrator
Self-Service User – Can manage assigned VMs only

Example:

New-SCRole -Name "DevOpsTeam" -UserRoleProfile "SelfServiceUser"

Add-SCUserRoleMember -UserRoleName "DevOpsTeam" -UserName "DOMAIN\DevUser1"

3. Self-Service Portal (Optional)

For non-admin users, provide a web-based portal:

Use Windows Azure Pack (WAP) or SCVMM Console
Users can start/stop/create VMs within limits

4. Use SCVMM Console or Web Access

Admins use SCVMM Console
Users can use WAP portal or PowerShell to manage their own VMs

Alternative (Less Ideal) Options

1. Remote Hyper-V Manager via MMC

Needs DCOM and CredSSP configuration
Not scalable or secure for many users

2. Windows Admin Center

Supports some multi-user scenarios
No RBAC or quota enforcement
Good for small teams, not enterprise-scale

3. PowerShell + Custom Portal

Build a custom web portal using PowerShell/REST API
High effort, high flexibility
Useful if you want to avoid SCVMM licensing costs

Recommended Design for Unlimited User Access

Component	Description
SCVMM	Core management + access control
Host Groups	Logical grouping of Hyper-V hosts by team/project
User Roles	Delegate access via RBAC
WAP or Custom Portal	Self-service interface for VM lifecycle tasks
SCOM (optional)	Monitoring and alerting
Azure Arc (optional)	Extend control plane to hybrid cloud

SCVMM Session Access and Limits

The maximum connections to SCVMM (System Center Virtual Machine Manager) depend on the SCVMM version, server roles, and how it's deployed (standalone vs. high availability). There isn't a single published "hard limit" on concurrent users or API calls, but here’s what Microsoft and real-world guidance suggest:

Key Connection Limits in SCVMM

Component	Guidance / Limit
SCVMM Console sessions	~50–100 concurrent users (recommended)
PowerShell/API sessions	~200+ concurrent sessions (scales with hardware)
SCVMM agents (hosts)	Up to 1,000 Hyper-V hosts per SCVMM server
VMs managed per SCVMM	Up to 25,000 VMs per instance (SCVMM 2019+)

Console Connection Behavior

Each SCVMM console session opens a WCF connection to the SCVMM service.
Too many consoles may exhaust WCF service threads, causing slowdowns or failed logins.
Recommended: no more than 50 concurrently active console users for performance.

For heavy workloads, SCVMM is not optimized as a multi-user interactive tool like vCenter—it's designed more for delegated/scoped automation and self-service.

Performance Considerations

If you expect many users managing VMs:

Use Role-Based Access Control to reduce scope.
Limit refresh and UI polling in consoles.
Offload heavy automation to runbooks or PowerShell instead of interactive sessions.
Consider deploying multiple SCVMM instances, scoped to host groups or regions, for scale-out.

Tips to Increase Scalability

Move SCVMM database to a dedicated SQL Server with enough CPU/RAM.
Use SCVMM Console in shared RDS or Citrix sessions to reduce client-side overhead.
Enable Dynamic Optimization and PRO Tips carefully—too frequent evaluations can strain performance.
Use self-service portals like Windows Azure Pack or custom UIs for large user bases.

Checking Current Connections

You can monitor current SCVMM sessions using:

Get-SCVMMServerConnection

Or monitor the SCVMMService.exe and WCF connections via Performance Monitor / Resource Monitor on the VMM server.

Example Real-World Limits (from Microsoft Docs / Experience)

SCVMM Version	Hosts Managed	VMs Managed	Console Users	API Sessions
2016/2019	~1,000	~25,000	~50–100	~200–500
2022	Similar, with improved scaling on modern SQL

High connection counts may cause:

Console slowness or timeouts
Delayed job execution
Errors like Unable to connect to VMM server
WCF throttling logs (Microsoft.SystemCenter.VirtualMachineManager)

Alternatives for Large User Access

Option	Benefit
SCVMM + Azure Pack	Delegated self-service with quota limits
Windows Admin Center	Lightweight admin tasks, no SCVMM dependency
Custom portals	Tailored REST or PowerShell access

2025-06-24T20:58:00.003-05:00

SCVMM VMWare to Hyper-V Conversion Overview

Overview

SCVMM (System Center Virtual Machine Manager) can convert VMware VMs (VMDK) into Hyper-V VMs (VHDX) through a V2V (Virtual-to-Virtual) conversion. It uses a library server as an intermediate storage and performs format conversion during the copy process.

Prerequisites

1. Environment Prep

· SCVMM must be installed and functioning.

· Add vCenter Server to SCVMM.

· Ensure the VMware VM tools are installed in the guest OS.

· SCVMM needs credentials to vCenter with read permissions.

· Create a Run As account for vCenter authentication.

· Target Hyper-V hosts must be available and managed in SCVMM.

2. Ports and Protocols

· SMB (TCP 445), WinRM (TCP 5985), BITS, and HTTPS (TCP 443) must be open between:

o SCVMM ↔ VMware ESXi/vCenter

o SCVMM ↔ Hyper-V hosts

o SCVMM ↔ Library server

Step-by-Step SCVMM V2V Conversion Process

Step 1: Add VMware Environment

1. Open SCVMM console.

2. Go to "Fabric" workspace.

3. Under "Infrastructure" > "vCenter Servers", right-click and choose "Add VMware vCenter Server".

4. Enter vCenter address and credentials (via Run As account).

5. Confirm discovery of VMware VMs and clusters.

Step 2: Prepare Conversion Target

1. Ensure a Hyper-V host is in a valid host group.

2. Prepare network sites, clouds, and storage classifications if needed.

Step 3: Initiate Conversion

1. Go to "VMs and Services" > right-click "VMware VM" > choose "Convert Virtual Machine".

2. Wizard opens:

o Select source VMware VM.

o Choose a target Hyper-V host or host group.

o Set destination path for VHDX.

o Map VM hardware (CPU, RAM, NICs, etc.).

o Select virtual network (match to Hyper-V network).

o Choose disk format: VHDX, and dynamic or fixed.

Tip: Choose dynamic VHDX to save space unless fixed-size is required for performance.

Step 4: Job Execution

· SCVMM:

o Copies the VMDK to a library server.

o Converts VMDK → VHDX.

o Places the new VHDX on the Hyper-V target.

o Creates and registers the new VM on the Hyper-V host.

· Monitor progress under "Jobs" in the SCVMM console.

Step 5: Post-Conversion Validation

· Power on the VM.

· Uninstall VMware Tools manually.

· Install Hyper-V Integration Services (if not already present; note that modern Windows VMs already include this).

· Validate network, storage, and service functionality.

Notes & Best Practices

Practice	Recommendation
Cold conversion	Recommended for consistency. Shut down VM before converting.
Clean guest OS	Remove unused files/apps before conversion to reduce size.
Library server tuning	Use SSD or NVMe-based storage for faster conversions.
No pass-through disks	SCVMM cannot convert VMs with RDMs or pass-through disks.
No snapshots	Convert only the current state of the VM.
Encryption	VMs with encrypted disks may fail to convert.

Proactive Approach Converting VMWare to Hyper-V VM’s

When using SCVMM (System Center Virtual Machine Manager) to convert VMware VMs to Hyper-V, there are a number of common issues you might encounter—especially when dealing with guest OS configurations, drivers, and disk formats. Below is a categorized list of real-world problems, their causes, and how to mitigate them.

Common Issues with SCVMM Conversions (VMware → Hyper-V)

1. VM Fails to Boot on Hyper-V

Problem	Cause	Fix
Black screen or boot loop	VMware bootloader/BIOS mismatch (e.g., EFI to BIOS)	Match firmware settings during conversion (BIOS vs. UEFI)
INACCESSIBLE_BOOT_DEVICE	Missing IDE/SCSI drivers or boot device mismatch	Inject Hyper-V-compatible storage drivers manually or convert to VHDX with correct controller
Boot device not found	Wrong boot order or missing boot partition	Check VM settings and disk layout post-conversion

2. Disk Conversion Issues

Problem	Cause	Fix
Disk size mismatch	Thin-provisioned disks misreported	Use RVTools to verify actual used size before conversion
Pass-through or RDM disks not migrated	SCVMM does not support these types	Remove or convert them to VMDK files first
Dynamic VHDX too large	Source disk is mostly empty but still copied entirely	Clean up VM prior to conversion, or use tools like StarWind V2V for leaner conversions

3. Hardware Compatibility Errors

Problem	Cause	Fix
VMware tools interfere with integration services	Conflicting drivers/services	Uninstall VMware Tools before or immediately after conversion
Device driver conflicts	Unsupported virtual hardware (VMXNET3, SCSI)	Replace with synthetic NICs or inject proper Hyper-V drivers in advance
Missing network connectivity	NIC not mapped to Hyper-V network or disabled	Map virtual NICs correctly during conversion wizard

4. SCVMM Job Failures or Timeouts

Problem	Cause	Fix
Job gets stuck in "Transferring"	Library server I/O bottleneck or large disk size	Use fast local SSD/NVMe on library server; avoid network-based VMDK
"Unsupported Guest OS" error	Guest OS not recognized or too old	Convert manually or upgrade OS before conversion
Network timeout or access denied	Firewall, credentials, or DNS resolution issue	Verify Run As accounts, ports (443/5985/445), and name resolution between SCVMM and vCenter/ESXi

5. Post-Conversion Guest OS Issues

Problem	Cause	Fix
Activation issues (Windows)	Hardware fingerprint change triggers reactivation	Use KMS or volume licensing where possible
Services don’t start properly	Dependency on VMware-specific hardware (VMCI, virtual CD, etc.)	Clean startup items and disable VMware-related services
Time skew or sync problems	Hyper-V time integration not active	Enable Hyper-V time sync service in VM settings

Best Practices to Avoid These Issues

Best Practice	Benefit
Cold-shutdown VMs before conversion	Reduces corruption risk
Clean up OS (temp files, drivers)	Minimizes conversion time and issues
Verify firmware type (UEFI/BIOS)	Ensures boot compatibility
Use updated integration services	Improves Hyper-V compatibility
Test conversion in lab first	Identify app or driver-level failures in advance
Monitor SCVMM logs (`Jobs` tab or Event Viewer)	Provides insight into failed stages

Tools for Troubleshooting

· RVTools – inventory thin vs. thick disks, OS, snapshots

· Event Viewer on SCVMM server – look for job failure codes

· Hyper-V VM boot logs – help debug guest-level issues

· Sysinternals tools – check services and drivers inside guest

· StarWind V2V Converter – fallback option for problematic conversions

Additional Prep Details from VMWare to Hyper-V

Key Differences That Affect Conversion Time

Provisioning Type	Description	Impact on Conversion
Thin-provisioned VMDK	Allocates space as data is written	Faster conversion — only actual data blocks are copied
Thick-provisioned VMDK	Allocates full disk size upfront	Slower conversion — full disk size is read, even unused blocks

Why Thick Disks Take Longer to Convert

· Thick disks are fully allocated (e.g., a 100 GB thick disk is actually 100 GB on disk, even if only 10 GB is used).

· During conversion, tools like Microsoft Virtual Machine Converter (MVMC), Disk2VHD, or SCVMM's built-in V2V processes must read and copy the entire 100 GB, not just the used space.

· Thin disks only copy the used portion of the disk, so a thin VMDK that uses 10 GB of actual data will only transfer 10 GB.

Conversion Tools & Behavior

Microsoft SCVMM

· Automatically converts VMDK to VHDX during migration.

· Attempts to detect actual data used, but performance depends on the source disk layout and whether the thick disk has zeroed blocks or not.

Third-party Tools (e.g., StarWind V2V, Disk2VHD, etc.)

· Behavior varies—some attempt to optimize by ignoring zeroed space, others copy all sectors.

Optimization Tips before Conversion

1. Defragment and zero out free space on thick disks using tools like sdelete from Sysinternals.

o This allows converters to detect unused space more easily.

2. Convert thick to thin on the VMware side before migration (if your policy allows).

3. Shrink partitions within the guest OS to reduce copied size.

4. Perform cold migration when possible for consistency and speed.

Estimated Migration Time Ranges

VM Disk Size	Thin Disk (used data only)	Thick Disk (full copy)
50 GB	~10–30 minutes	~30–60 minutes
100 GB	~30–60 minutes	~60–120 minutes
500 GB	~1.5–3 hours	~3–6 hours
1 TB	~3–5 hours	~6–10+ hours

Note: Assumes 1 Gbps network, moderate disk I/O, and no heavy workloads during migration.

What Affects Migration Speed?

Factor	Impact on Time
Disk Provisioning (Thin vs Thick)	Thin is faster—only real data is copied
Disk Usage	Less data = faster
Storage IOPS	Slow reads or writes increase time
Network Bandwidth	1 Gbps vs. 10 Gbps makes a big difference
Live vs Cold Migration	Cold is often faster and safer
Conversion Tool	Some tools optimize block copying better
Compression or Deduplication	Can help reduce copy size
Source and Destination Format	VMDK → VHDX adds conversion overhead

Tool-Specific Speeds (Generalized)

Tool	Notes
Microsoft SCVMM (V2V)	Efficient, but requires careful config; uses SMB/NFS/HTTP
MVMC (Legacy)	Older, slower, and no longer supported
StarWind V2V Converter	Fast and lightweight; good for one-offs
Disk2VHD + Manual import	Lightweight, but needs manual cleanup
Cloud-based tools (e.g., Azure Migrate)	Adds more time for staging and cloud prep

Where to Find Thin vs. Thick Provisioning in RVTools

· Open RVTools and go to the vDisk tab.

· Look for the column named:

o thinProvisioned

§ Value: true = thin provisioned

§ Value: false = thick provisioned

SCVMM Concurrent Conversions Overview

The number of concurrent V2V (VMware to Hyper-V) conversions you can run in System Center Virtual Machine Manager (SCVMM) is not hard-coded, but it's limited by system resources and SCVMM configuration.

Here's a breakdown of how many you can expect and how to scale it:

Typical Concurrent Conversion Capacity

SCVMM Resource Tier	Recommended Max Concurrent Conversions
Default SCVMM setup (single library server, average resources)	2–4
Well-resourced SCVMM + dedicated library server	5–10
Optimized setup with tuning and monitoring	10–15 (with caution)

Running more than 5–6 at a time on default setups can slow down conversions or cause failures, especially if disk or network bandwidth is limited.

What Limits Concurrent Conversions

Limiting Factor	Impact
Library Server bandwidth and IOPS	All conversions route through it
Conversion method (online/cold)	Live conversions are slower and more resource intensive
Host CPU & RAM	Conversion agents use these heavily
Network throughput	VMware > SCVMM > Hyper-V host data path
Storage target performance	Bottleneck if multiple VMs are written at once
SCVMM job scheduler	Limits job concurrency to avoid overload

How to Increase Concurrent Conversion Capacity

1. Use a fast, dedicated Library Server

o SSD storage and 10 Gbps NICs recommended.

2. Stagger migrations

o Use PowerShell or orchestration to batch conversions (e.g., 3 at a time).

3. Monitor SCVMM job throughput

o Avoid scheduling other heavy SCVMM jobs simultaneously.

4. Use a distributed SCVMM architecture

o Deploy additional hosts and scale out with performance tiers.

5. Move source and target storage closer together

o Avoid cross-site or low-bandwidth conversions.

PowerShell for Controlled Parallel Conversions

You can use PowerShell to limit parallel conversions by queueing jobs:

## powershell

$VMsToConvert = Get-SCVMWareVM | Where-Object { $_.Name -like "AppServer*" }

$MaxConcurrent = 3

$Queue = New-Object System.Collections.Queue

$VMsToConvert | ForEach-Object { $Queue.Enqueue($_) }

while ($Queue.Count -gt 0) {

    $jobs = @()

    for ($i = 0; $i -lt $MaxConcurrent -and $Queue.Count -gt 0; $i++) {

        $vm = $Queue.Dequeue()

        $jobs += ConvertTo-SCVirtualMachine -VMwareVM $vm -JobGroup (New-Guid) -RunAsynchronously

    $jobs | Wait-Job

References

Convert a VMware VM to Hyper-V in the VMM fabric | Microsoft Learn

Convert VMware VMs to Hyper-V faster with SCVMM | Microsoft Community Hub

V2V Converter / P2V Converter - Converting VM Formats

RVTools | Installer | 4.7.1 Installer | Dell US

2025-06-24T20:57:00.002-05:00

Citrix Debug HDX with WireShark

Overview

Wireshark can capture and analyze HDX/ICA traffic, but to make it effective, you should combine it with Citrix display protocols (ICA/HDX) filters, DTLS decryption (if possible), and custom profiles or scripts that highlight latency, retransmissions, and protocol behavior.

Below is a guide to capture HDX session traffic, along with custom Wireshark filters and templates for debugging ICA latency, EDT issues, and HDX performance bottlenecks.

Wireshark HDX/ICA Debugging Setup

Step 1: Capture Traffic

Run Wireshark on the endpoint or VDA
Capture on the NIC (e.g., Ethernet or Wi-Fi)
Use this capture filter to limit traffic:

host <VDA IP> and (tcp port 1494 or tcp port 2598 or udp port 443)

1494 = ICA, 2598 = Session Reliability, 443 UDP = EDT/DTLS

Wireshark Display Filters for HDX/ICA Analysis

Use these display filters in Wireshark after capture to drill into ICA traffic:

Basic HDX Filters

tcp.port == 1494 || tcp.port == 2598 || udp.port == 443

EDT / DTLS Transport

udp.port == 443 && dtls

ICA Retransmissions (high latency symptom)

tcp.analysis.retransmission || tcp.analysis.fast_retransmission

Round-Trip Time Analysis

tcp.analysis.ack_rtt

Then go to:
Statistics → TCP Stream Graphs → RTT to visualize latency spikes.

Wireshark ICA/HDX Profile or Script

You can create a custom Wireshark profile to automatically apply filters and coloring rules.

Here’s what you can include in your profile:

Coloring Rules

Rule Name	Filter	Color
ICA TCP	tcp.port == 1494	Blue
Session Reliability	tcp.port == 2598	Green
EDT/UDP	udp.port == 443	Orange
Retransmission	tcp.analysis.retransmission	Red
High RTT	tcp.analysis.ack_rtt > 0.200	Yellow

To create a profile:

Wireshark → Help → About → Folders → find your profiles directory
Create folder CitrixHDX
Inside it, create:

colorfilters file with above rules
dfilters file with your ICA filters
Save and switch to the CitrixHDX profile in Wireshark

Exportable Scripts and Tools

Citrix offers CDFControl for component tracing, and that can work alongside Wireshark
NetScaler Trace (nstrace) can be opened in Wireshark for ICA-level visibility (especially EDT over Gateway)
Combine ctxmonitor logs with Wireshark trace timestamps to correlate spikes

DTLS Decryption?

If using EDT (UDP/DTLS), the traffic is encrypted and not readable in Wireshark unless:

You capture on the VDA before encryption
OR you perform a NetScaler nstrace with decryption enabled

Otherwise, you're mostly checking packet size, jitter, and flow, not content.

Example Use Case

To trace EDT fallback to TCP, apply:

frame contains "X-Citrix-Transport"

Look for changes like:

X-Citrix-Transport: UDP -> TCP

This is your smoking gun that EDT failed and fell back to TCP — often causes latency jumps.

2025-06-24T20:55:00.004-05:00

Citrix Netscaler Best Practices for DaaS HDX

Overview

Optimizing NetScaler (Citrix ADC) for HDX traffic is crucial for low-latency, high-performance Citrix sessions — especially under load or in hybrid/WAN conditions.

The following details provide recommendations to the best practices for configuring NetScaler for HDX/ICA traffic, organized by key areas:

1. General Configuration Best Practices

Setting	Best Practice
Use Gateway vServer (ICA Proxy)	For secure remote access to HDX traffic (SSL offload, SmartAccess).
Enable DTLS (UDP)	Required for HDX Adaptive Transport (EDT over UDP) – reduces ICA latency.
Ensure UDP 443 or 1494/2598 is open	Adaptive Transport requires bi-directional UDP to be allowed through firewalls.
SSL Profile with TLS 1.2+	Avoid TLS 1.0/1.1 for security and performance (some TLS overhead affects ICA).
Configure ICA Only Session Policy	Filters traffic to only ICA (if using multiple app types).

2. Optimize for HDX Adaptive Transport (EDT)

Feature	Recommendation
Enable HDX Adaptive Transport	Set Citrix policy HDX Adaptive Transport to Preferred or On.
Enable DTLS on the Gateway vServer	Required to use UDP for ICA (EDT).
Configure Firewall/NAT to Allow UDP 443	For public clients — don't let NAT break UDP connections.
Fallback to TCP must be clean	Ensure TCP fallback doesn’t cause disconnects or spike latency.

3. ICA Session Reliability and Load Handling

Setting / Tip	Recommendation
Enable ICA Session Reliability	Ensures smoother experience during short network interruptions.
Use Load Balancing on VDAs (if applicable)	Distribute traffic to avoid server-side bottlenecks.
Enable Multipath or GSLB (for global users)	Improves latency by routing users to closest datacenter.
Limit ICA Proxy session timeouts	Prevents stale sessions and optimizes gateway memory use.

4. Security + Performance Trade-offs

Feature	Recommendation
Disable SSL Renegotiation	Reduces overhead and prevents denial-of-service attack vectors.
Enable SSL Session Reuse	Reduces handshake overhead and improves ICA connection setup time.
Tune TCP Profiles	Customize TCP buffer sizes, window scaling for ICA responsiveness.
WAF and AppFW Bypass for ICA	Do not apply full WAF inspection to HDX traffic — it’s not HTTP/S.

5. Monitoring and Troubleshooting

Tool/Feature	Use It For
AppFlow / HDX Insight	Real-time visibility into ICA latency, bandwidth, retransmits.
NetScaler MAS or ADM	Historic reports, alerts, user session data.
nstrace / Wireshark	Deep packet inspection to verify EDT vs TCP, retransmits.
Policy Hits & Logging	Confirm users are hitting correct session policies.

6. Policy Configuration Recommendations

Session Profile Field	Recommended Value
ICA Only	ON (if you only publish Citrix apps/desktops)
Client Choices	OFF (hide options from end users)
Split Tunnel	OFF (unless explicitly needed for internal apps)
Session Timeout	900–1200 seconds depending on security requirements
DTLS	ENABLED (for EDT over UDP)
TCP Profile	Use a custom TCP profile optimized for low latency

Optional Enhancements

Consider enabling QUIC (HDX over QUIC is being explored in modern versions).
Transition to Citrix Cloud + Gateway Service for cloud-native HDX delivery and automatic optimization.
Use adaptive traffic steering via GSLB for users in different geos (with ADM or SD-WAN integration).
Enable zero trust contextual access (GeoIP, device posture) for HDX sessions via SmartAccess.

Deep Dive SSL/TLS Handshack Delays

Reducing SSL/TLS handshake delay is critical for improving HDX (ICA) session launch times, especially in NetScaler Gateway environments. The details below outlines configurations on minimizing SSL/TLS handshake overhead while maintaining strong security:

What Causes SSL/TLS Handshake Delays?

TLS handshakes involve:

· Cipher negotiation

· Certificate exchange

· Key exchange (DH, ECDHE)

· Server-side CPU usage

· Network RTT (round-trip time)

Each step introduces latency if not optimized.

Best Practices to Reduce SSL/TLS Handshake Delay

1. Use Modern, Efficient Cipher Suites

· Prefer ECDHE-based ciphers (Elliptic Curve Diffie-Hellman Ephemeral) for faster key exchange and forward secrecy.

· Disable RSA key exchange and 3DES, which are slow and outdated.

Recommended Cipher Group (NetScaler):

shell

add ssl cipher CUSTOM-HDX-CIPHERS

bind ssl cipher CUSTOM-HDX-CIPHERS -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -priority 10

bind ssl cipher CUSTOM-HDX-CIPHERS -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -priority 20

Then bind it to your Gateway vServer:

shell

set ssl vserver <vServerName> -cipherName CUSTOM-HDX-CIPHERS

2. Enable TLS Session Resumption (Session Caching & Tickets)

· Session Resumption avoids full handshakes for repeat connections.

On NetScaler:

shell

set ssl parameter -sessReuse ENABLED -sessTimeout 300

Also enable TLS Session Tickets for better compatibility:

shell

set ssl parameter -enableSessionTickets YES

3. Use Smaller, Modern Certificates

· Prefer 2048-bit RSA or ECC certificates (e.g., ECDSA P-256) which are faster than 4096-bit RSA.

· ECC certs reduce handshake size and compute time.

ECC certs need both ADC and clients to support them (modern OS/browser/workspace apps do).

4. Optimize SSL Profile & Protocol Settings

· Use an SSL Profile and attach it to vServers for centralized config.

Recommended SSL Profile Settings:

Setting	Value
Protocols	TLS 1.2 only (optionally 1.3 if fully supported)
SSLv3, TLS 1.0/1.1	DISABLED
DH Key Expiration	0 (disable regeneration)
SSL Renegotiation	DISABLED
SSL Session Timeout	300–600 seconds

Example:

shell

set ssl profile HDX-SSL-PROFILE \

  -tls1 DISABLED -tls11 DISABLED -tls12 ENABLED \

  -sessReuse ENABLED -enableSessionTickets YES \

  -denySSLReneg NONSECURE

5. Disable SSL Renegotiation

Renegotiation can introduce delay and vulnerabilities.

shell

set ssl vserver <vServerName> -denySSLReneg NONSECURE

6. Minimize Round-Trip Time (RTT)

· Place Gateway as close to the users as possible (GSLB, PoPs, SD-WAN).

· Offload SSL processing to NetScaler (not backend servers).

· Ensure no WAN acceleration or SSL inspection devices delay the handshake.

Optional Enhancements (Future-Proofing)

· TLS 1.3: Much faster handshakes (1-RTT or 0-RTT with session tickets), supported on newer NetScaler versions (13.1+).

· QUIC (UDP-based TLS): Citrix is exploring HDX over QUIC in future builds.

Tools to Measure Handshake Performance

· Wireshark: Filter on ssl.handshake and measure timing between ClientHello and Finished.

· Citrix ADM: SSL dashboard → handshake stats per vServer.

· OpenSSL CLI:

bash

openssl s_time -connect yourgateway.company.com:443

References

Security considerations and best practices | Citrix Virtual Apps and Desktops 7 2503

Tech Paper: Security best practices for Citrix Virtual Apps and Desktops - Tech Papers

Best practices for NetScaler MPX, VPX, and SDX security

Best practices for network configurations | Networking

2025-06-24T20:54:00.003-05:00

Windows Server 2022 VMware Setup and Prep for Sysprep

To ensure Windows Server 2022 Datacenter on VMware fully supports Sysprep, your VM needs to meet a few critical requirements related to firmware, configuration, and image integrity.

Here’s a step-by-step guide to prepare your VM for successful Sysprep execution:

1. Create VM with the Correct Settings

When creating the VM in vSphere or Workstation:

Firmware

Firmware: Set to UEFI (not BIOS).

In vSphere: VM Options > Boot Options > Firmware = UEFI
Disable Secure Boot unless you have a specific need for it.

Guest OS

Choose Windows Server 2022 or later (64-bit) for proper driver support.

Virtual Hardware

At least hardware version 14 or later is recommended.

2. Install Windows Server 2022 Properly

Use a clean ISO install (not a customized or heavily preconfigured image).
During install, Windows Setup should automatically create a proper EFI system partition (ESP) formatted as FAT32.

3. Avoid Common Pitfalls

Do NOT:

Switch firmware (BIOS ↔ UEFI) after install.
Install or leave Windows Store apps or provisioning packages.
Leave pending updates or rollbacks before Sysprep.

4. Verify Before Running Sysprep

Run this checklist inside the OS:

Confirm UEFI Mode

(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control").PEFirmwareType

# Should return: 2 (UEFI)

Check EFI Partition

diskpart

list disk

select disk 0

list partition

You should see a FAT32 partition labeled "System" (usually ~100MB).

Validate BCD

bcdedit /enum all

Confirm entries like bootmgr, default, and proper device paths.

5. Run Sysprep Properly

From an elevated Command Prompt:

cd %windir%\System32\Sysprep

sysprep.exe /generalize /oobe /shutdown /mode:vm

Use /mode:vm for VMs—this tells Sysprep not to remove VM-specific drivers.

6. If You’re Using Templates (Optional)

Shut down the VM after Sysprep completes.
Take a snapshot or convert it to a template in vCenter.
When deploying from template, customize using Guest Customization Specification in VMware.

As of June 2025, Windows Server 2022 is officially supported on the following VMware ESXi versions:

Supported ESXi Versions for Windows Server 2022 (as Guest OS)

vSphere 7.x

ESXi 7.0 Update 2 (Build 17867351 and later)
- Official support for Windows Server 2022 was added with this release.

vSphere 8.x

ESXi 8.0 GA and all updates
- Fully supports Windows Server 2022 as a guest OS.
- Offers improved performance, better hardware support, and security features (e.g., TPM 2.0 passthrough for Secure Boot/VDI).

Reference

VMware’s Compatibility Guide (https://www.vmware.com/resources/compatibility/search.php) confirms guest OS support per release.

Search keywords:

Product: ESXi
Guest OS: Windows Server 2022

Additional Notes

VM Hardware Version: Use version 19 or later (recommended for ESXi 8.x) for full feature support (e.g., vTPM, secure boot, UEFI).
VMware Tools: Ensure the latest version is installed for best driver and integration support.
Cluster Features: DRS, HA, and snapshots are supported.

2025-06-24T20:51:00.000-05:00

SCVMM and SQL Server Sizing Guide

Overview

The following details outlines the compute requirements for System Center Virtual Machine Manager (SCVMM) and its associated SQL Server database, based on current best practices and Microsoft's guidance for System Center 2022. These specs can vary depending on your environment size, so I’ll break it down into minimum, recommended, and scalable (large environments).

SCVMM Server Compute Requirements

Minimum Requirements (Lab / Small environments)

· CPU: Dual-core, 2.0 GHz (64-bit)

· RAM: 4 GB minimum

· Disk: 20 GB for installation (not including library or logs)

Recommended Production Requirements

· CPU: Quad-core, 2.5+ GHz (64-bit)

· RAM: 8–16 GB

· Disk:

o 40+ GB for OS and SCVMM binaries

o Separate disk or volume for SCVMM library share

o Fast storage (SSD preferred) for responsiveness

Large / Enterprise Environments

· CPU: 8+ cores

· RAM: 32+ GB (especially with high host count or large VMM fabric)

· Disk:

o OS: SSD

o Library: Dedicated volume with fast IOPS

o Logging: Consider dedicated volume if using diagnostics or high audit activity

SQL Server for SCVMM

SCVMM supports SQL Server 2019 and 2022 (Standard or Enterprise). SQL Server should be on a separate box in production for scalability and HA purposes.

Minimum Requirements

· CPU: Quad-core

· RAM: 8 GB

· Disk: 40 GB (with fast storage for data + tempdb)

Recommended for Medium Environments

· CPU: 8 cores

· RAM: 16–32 GB

· Disk:

o OS: SSD

o Data: SSD or high-performance RAID

o Logs: Separate volume from data

o TempDB: Separate volume if performance is a concern

Large Environments / HA

· SQL Always On Availability Groups or Failover Clustering

· CPU: 16+ cores

· RAM: 64 GB+

· High-performance SAN or SSD storage with separation of:

o OS

o Data files

o Log files

o TempDB

Other Considerations

· Network: 1 Gbps minimum; 10 Gbps strongly recommended for production environments

· Windows OS:

o SCVMM: Windows Server 2022 or 2019 (latest supported build)

o SQL Server: Same

· Domain: Both SCVMM and SQL must be domain-joined

· Service Accounts: Use separate, least-privileged accounts for SCVMM and SQL services

· SCVMM Scale-Out:

o SCVMM supports scaling out via multiple consoles and PowerShell clients, but there is only one VMM server per VMM database.

Tiered Sizing Recommendations

Tier	Hosts	VMs	SCVMM Specs	SQL Server Specs
Small	< 10	< 250	4 vCPU / 8 GB RAM 100 GB disk (OS + logs)	4 vCPU / 16 GB RAM 100 GB disk (data + logs)
Medium	10–50	250–1,500	8 vCPU / 16 GB RAM 150–200 GB disk + separate VMM Library disk	8 vCPU / 32 GB RAM Dedicated disks: - 100 GB OS - 200 GB DB - 100 GB logs - 50 GB TempDB
Large	50–200	1,500–5,000	12–16 vCPU / 32–64 GB RAM SSD storage with 300+ GB usable	16 vCPU / 64+ GB RAM SSD or SAN storage with separation: - OS - Data - Logs - TempDB
Enterprise	200+	>5,000	Clustered or Highly Available SCVMM Centralized SCVMM Library (DFS or SAN)	SQL Always On / Cluster Multi-tiered disk architecture Up to 128 GB RAM, 24+ cores

Scalability tested up to:

· 1,000 hosts

· 25,000 VMs

Notes by Component

SCVMM

· More RAM improves performance when managing large host groups or doing frequent PowerShell jobs.

· VMM Library performance is critical when doing template deployments — consider moving it to high-speed network storage (SMB 3.0 or SAN-backed).

· SCVMM performance also depends on network I/O, especially when deploying or migrating VMs.

SQL Server

· SQL workload grows significantly with:

o Large fabric definitions (many hosts, logical networks, etc.)

o Frequent job scheduling (e.g., deployments, compliance scans)

o High audit settings enabled

· You can place TempDB on SSD for performance — SCVMM uses it heavily.

Future-Ready Best Practices

1. Separate SCVMM and SQL roles — never co-host them in production.

2. Enable SQL Maintenance Plans for SCVMM DB (index rebuilds, statistics updates).

3. Monitor SQL latency and deadlocks — SCVMM performance often bottlenecks there.

4. Use SCVMM high availability only if absolutely needed — it's single-active and can be complex to maintain.

5. Consider System Center Operations Manager (SCOM) to monitor SCVMM at scale.

6. If using SCVMM with Azure Stack HCI, lean on Azure Arc and hybrid tooling.

SQL Always On for SCVMM – Planning Guide

1. SQL Version: Use SQL Server 2019 or 2022 Enterprise Edition.
2. Deployment Type: Always On Availability Group with synchronous replication and automatic failover.
3. Cluster Configuration:
    - Minimum 2 nodes
    - Windows Server Failover Clustering (WSFC) enabled
    - Shared domain, same Active Directory site for low latency
4. Listener:
    - Create an Always On Availability Group Listener
    - Use this listener name when installing SCVMM (for automatic failover support)
5. Storage:
    - Separate volumes for Data (.mdf), Logs (.ldf), and TempDB
    - SSD/NVMe or SAN-backed storage with redundancy
6. Backups & Maintenance:
    - Use full, differential, and transaction log backups
    - Run index maintenance and statistics updates regularly
7. VMM-Specific Note:
    - SCVMM does not support database failover clustering instances (FCI), only Always On AGs.
    - If using AG, SCVMM must connect via the listener DNS name, not the individual SQL instance.
8. Test Failover:
    - Validate SCVMM continues operating normally post-failover.
    - Review SCVMM logs in Event Viewer and SQL Server logs for any issues.

References

System requirements for Virtual Machine Manager | Microsoft Learn

Reviewing minimum requirements for Microsoft Hyper-V environments - BMC Documentation

Plan VMM installation | Microsoft Learn

VMWare Horizon View vGPU M10 Bad Performance Updated - Horizon 7.x

2020-10-27T15:38:00.003-05:00

Workaround - Fixed in 7.12 Release

https://communities.vmware.com/thread/603823

Below is a combination of settings we use to achieve satisfactory performance:

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware SVGA DevTap]

"Win32FrameRate"=dword:0000002d

"MaxAppFrameRate"=dword:0000002d

"ForceWin32Capture"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Teradici\PCoIP\pcoip_admin_defaults]

"pcoip.audio_bandwidth_limit"=dword:000001c2

"pcoip.enable_build_to_lossless"=dword:00000000

"pcoip.enable_console_access"=dword:00000000

"pcoip.minimum_image_quality"=dword:00000028

"pcoip.maximum_initial_image_quality"=dword:00000050

"pcoip.maximum_frame_rate"=dword:0000002d

"pcoip.use_client_img_settings"=dword:00000000

The config is for 45FPS which is the maximum we can achieve with our current NVIDIA license.

We already spoke with VMware and they confirmed that is indeed a workaround for now, until they get Teradici to fix PCOIP code.

VMWare Horizon View Instant Clone Errors during Proviosning

2020-10-27T15:29:00.000-05:00

Horizon

Troubleshooting Instant Clones in the Internal VM Debug Mode

Last Updated 09/01/2017 1

Add To MyLibrary

< Ask New Question

You can use the internal VM debug mode to troubleshoot internal virtual machines in instant-clone desktop pools. With the internal VM debug mode, you can analyze failed internal virtual machines before these virtual machines are deleted. You must enable the internal VM debug mode before you create an instant-clone desktop pool.

Procedure

In the vSphere Web Client, select the master VM, and click Manage > Configure > VM Options > Edit > VM Options > Advanced > Edit Configuration.
The Configuration Parameters window displays a list of parameter names and values.
In the Configuration Parameters window, search for the cloneprep.debug.mode parameter.
If the master VM does not have the cloneprep.debug.mode parameter, you must add cloneprep.debug.mode as the parameter name and add a value of ON or OFF. If the master VM has the cloneprep.debug.mode parameter, you can change the value of the parameter to ON or OFF.
Enable or disable the internal VM debug mode for internal VMs.
- To enable the internal VM debug mode, set the value of cloneprep.debug.mode to ON. If you enable the internal VM debug mode, the internal VMs are not locked and cannot be deleted by Horizon Server.
- To disable the internal VM debug mode, set the value of cloneprep.debug.mode to OFF. If you disable the internal VM debug mode, the internal VMs are locked and can be deleted by Horizon Server.
For instant clones actions such as prime, provision, resync, or unprime, the internal virtual machines use the value set in the master virtual machine. If you do not disable the internal VM debug mode, then the VMs remain in vSphere till you delete the VMs.

Instant Clones provisioning fails with the error: "Unable to prepare migration" (60397)

Last Updated: 12/19/2018Categories: Troubleshooting 1Language:

Symptoms

When creating a new Horizon Instant Clones pool or during Push Image/Maintenance operation on Horizon Instant Clones pool, you experience these symptoms:

Some of the Horizon Instant Clones fail with the error:

Unable to prepare migration.
This error is visible on vCenter Server tasks for all the clones that failed.

Cause

This issue occurs because very rarely on vSphere 6.7, a cp-parent VM fails to quiesce properly. This causes "Unable to prepare migration" error when creating Horizon Instant Clones.

Resolution

This is a known issue affecting VMware vSphere 6.7.x with Horizon 7.5 and later.

Currently, there is no resolution.

Workaround

To work around this issue, follow either one of the workarounds:

Workarounds for on-prem Horizon deployment

Workaround #1

Identify the cp-parent VM that is causing the failures by looking at the vCenter Server tasks.

Navigate to the host on which this cp-parent VM resides.
Set InstantClone.Maintenance attribute to value 1 in "Custom Attributes" on the the "Summary" page of the host. This deletes all the cp-parent VMs from the host, including the problem one.
Once the cp-parent VMs are deleted, the host InstantClone.Maintenance will be set to 2.
Edit the InstantClone.Maintenance attribute value to an empty string.
Enable provisioning on the pool or recover the clones in error state.

Workaround #2

Identify the cp-parent VM that is causing the failures by looking at the vCenter Server tasks.

Navigate to the host on which this cp-parent VM resides.
Put the host into maintenance mode. This deletes all the cp-parent VMs from the host, including the problem one. The host will enter maintenance mode once all cp-parent VMs on it are deleted.
Exit the host from maintenance mode.
Enable provisioning on the pool or recover the clones in error state.

Workaround for Horizon instances on VMC

Identify the cp-parent VM that is causing the failures by looking at the vCenter Server tasks.

Navigate to the host on which this cp-parent VM resides.
Power off the cp-parent VM and delete it.
Enable provisioning on the pool or recover the clones in error state.

https://communities.vmware.com/thread/619413

Horizon 8 2006 - The Next-Generation of End User Computing from VMWare is Ready

2020-09-28T15:25:00.001-05:00

Horizon 8 2006 Overview

Horizon 8 2006 is now available and I am using this new release exclusively moving forward for new installations and upgrades. So far I have been pleased with the ease of implementation and configuration, upgrades and ability to utilize vSphere 7.

Below are some really good links to review before going down the Horizon 8 Path and some details from https://techzone.vmware.com/blog/whats-new-vmware-horizon-8-2006-cart-app-volumes-and-dynamic-environment-manager

Release Notes

https://docs.vmware.com/en/VMware-Horizon/2006/rn/horizon-2006-release-notes.html

Compatibility Guide

https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

Horizon 8 Upgrade Guide

https://www.vmware.com/products/horizon/upgrade-center.html

Blog Regarding Release

https://blogs.vmware.com/euc/2020/08/vmware-horizon-8.html

Horizon 2006 Platform Updates

Here are some of the most notable new enhancements and updates to the platform:

Branding and Versioning. We’ve moved to the YYMM-style format to version the Horizon Server, Horizon Client and Horizon Agent. This new format applies to product installations and Horizon Console as well.
Updates to Core Platform. Horizon 2006 now supports parallel upgrades of Connection Servers. Note that this applies to a maximum of 3 pods at a time in parallel. If another host in a local or global pod is in an inconsistent state, the installer is blocked.
- Up to 32 GB of cache in CBRC 2.0 is now supported, up significantly from 2 GB in CBRC 1.0.
- False memory alarm for IC Parents on vSphere 7.0 can be removed.
- Note that now HTML is on by default for desktop pools and RDSH farms.
Deployment Options. You can now choose your deployment environment when you set up a new pod, during the connection server installation process. The following deployment environments are supported, and help you determine how the installation will be completed:
- General (typical vSphere On-Premises)
- AWS (either VMware Cloud on AWS, or EC2 Native)
- Dell EMC (the VMware Cloud on Dell EMC solution)
- Azure (the Azure VMware Solution solution)
- Google Cloud (the Google Cloud on VMware Engine)
- Oracle Cloud (the Oracle Cloud on VMware Engine)
  Note: This option is available only when setting up a new pod. Subsequent pods use the deployment options that were set in the first.
Digital Watermark. You now have the option of configuring a digital watermark for ownership protection, authenticity, and verification of intellectual property. This allows you to prove ownership and establish a chain of custody on your property. You can set up variables in the watermark, such as IP address, username, domain name, and so on, as well as customizing the opacity, margin, and layout.
REST API. This release offers a plethora of new endpoints, including entitlements and inventory sections that include many new options. This release also includes a Swagger UI that is available locally on the installation. Visit https://<FQDN of your connection server>/rest/swagger-ui.html to see the REST APIs, learn about them, explore their endpoints, and test them out.
For more information, see Using the VMware Horizon Server REST API. https://techzone.vmware.com/resource/using-vmware-horizon-server-rest-api
Smart Provisioning. Horizon automatically choose the type of desktop to create, based on density of VMs per host in selected cluster. Low density types are created without parent VMs, high density are created with parent VMs. Horizon directly clones replica without a parent VM, which takes a lot of memory and disk space. This lowers the number of parent VMs in lower-density clusters, and reduces the footprint. For high density, traditional instant clones are created with parent VMs. To learn how this works, including how to force it instead of relying on the automatic functionality, see VMware Horizon Version 8 (2006) – Feature Overview: Instant Clone Smart Provisioning.

Feature mapping. If you compare Horizon 8 (2006) to Horizon 7, you will notice some deprecated features, such as linked clones in the Composer and persistent disks. These features still exist, but are slated to be removed in a future version. Some features have been removed, such as support for older versions of Windows, the JMP Server, persona management, FLEX admin, ThinPrint, and Security Server, all of which have been replaced by newer functionality. Note that instant clones are now available across all license types.
Deprecation notifications have been added to the UI to remind you of the features that are now deprecated and slated to be removed in a future release.
Linked Clone/Instant Clone Gaps. There are a few feature gaps between linked clones and instant clones, which might be reason to continue using linked clones until the gaps are filled. Gaps include unique BIOS IDs, multi-NIC, Sysprep for Instant Clones, and statically assigned computer names.

Horizon Console

You will find the following new features and enhancements in the VMware Horizon Console:

General Updates

A number of general updates are included in the new Horizon Console, including the ability to set a display name for global entitlements, an improved grid where more detailed data can be displayed in the easy-to-read layout.

Horizon Client Restrictions

This release includes a restriction against connecting with older Horizon Clients:

In Global Settings, you can configure multiple criteria for what to block, and set up a customized warning message to remind users to upgrade. Only the 8.x (2006) client and later versions can support this warning message (it is not supported on thin clients).

More Detail on Network Display

You can now see many more details on ports, which is helpful when selecting a network during the pool creation process. This includes details about the individual network such as binding, network name, total ports, and available ports, as well as incompatible network types.

In-Product Feedback

You can now send direct in-product feedback to the product teams in 11 languages. The static format is always available (see the bubble in the upper right corner of your console):

The popup format is also available, based on logins and duration. You also have the ability to opt out.

Client Restrictions for Desktop Pools

You can now set it up so that only privileged workstations can connect to a pool. To do this, create an entitlement that restricts both the user and the desktop, so that the specific user must use a specific desktop.

Linux Desktop

You now have support for Red Hat Enterprise Linux 7.8, as well as multi-session support on Red Hat 7.8, 8.1, and Ubuntu 1804. You can set it up by installing a Linux agent with --multiple-session and see a demonstration at https://techzone.vmware.com/vmware?share=video2743.

Blast Extreme

This release gives you a number of improvements to full-screen video and memory utilization in Blast Codec, which is now enabled by default. You can also enjoy support for HEVC 4:4:4 Codec with Intel CPUs, which is the 10th generation of Intel Ice Lake. This is Windows VMs only with the 2006 client, and it is on by default if the hardware exists. In addition, there is support for up to two 8K monitors, and an improvement to how the client topology is sent.

Horizon Agent

This release includes new optimizations in real-time audio and video, including H.265 encode and decode. These optimizations improve the user experience for webcam usage and video conferencing. Support includes Zoom, Microsoft Teams, and Skype for Business, as well as Windows Tablet.

Location-Based Printing UI – VMware Integrated Printing

With a new UI, you can set up location-based printing in VMware Integrated Printing. You configure this in the GPO Bundle and set location-based printing parameters, which flow to the endpoint.

Horizon Clients

Each type of Horizon client has new enhancements and updates, including the new Client Restriction Messages mentioned earlier. You will see this option in the UI of all Horizon Clients.

Video and Desktop Sharing Optimization – Microsoft Teams

This popular feature is optimized for video and desktop sharing with Microsoft Teams on Horizon 2006. A specific set of configurations are supported, including Horizon 2006 Server, Horizon 2006 Windows Client, and that has Teams for VDI installed with the per machine option enabled. Note that this is not supported on RDS desktop pools or application pools.

Windows Client

In addition to the new Client Restriction Message mentioned earlier, the Horizon Windows Client also includes Windows 10 2004 support, Microsoft Edge Chromium support for URL redirection, and the option to skip certification revocation list checking.

Linux Client

In addition to the Client Restriction Message, the Horizon Linux Client also now supports Ubuntu 20.04 LTS, full IPv6, custom display resolutions, and an updated SDK that allows you to customize the Linux client and get more brokering and remote sessions data.

Mac Client

In addition to the Client Restriction Message, the Horizon Mac Client now has USB auto-connect for RDSH apps.

iOS Client

In addition to the Client Restriction Message, the Horizon iOS now supports VMware Integrated Printing, including location-based printing options.

Android Client

In addition to the Client Restriction Message, the Horizon Android Client also supports VMware Integrated Printing, as well as the ability to pass the Android device ID to OPSWAT.

Chrome Client

In addition to the Client Restriction Message, Horizon Chrome Client also now supports ChromeOS 81 and ChromeOS 82.

HTML5 Client

In addition to the Client Restriction Message, the Horizon HTML5 Client now supports Edge Chromium, as well as the option to save the monitor layout on Windows, MacOS, and ChromeOS desktop endpoints.

VMware App Volumes

The new release of VMware App Volumes includes a variety of new enhancements and updates, including the new naming convention:

Improvements in this release include performance improvements to speed up user logins, diverse application support, and more. Here’s a summary of some of the most notable improvements:

Microsoft LDAP Channel Binding

App Volumes Manager is upgraded to now communicate with Domain Controllers configured for LDAP Channel Binding, in keeping with the March 2020 ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing. App Volume Manager and App Volumes Agent 2006 4.1 are required, and Channel binding support is enabled by default. Note that the LDAP AVM setting works only if AD LAPServerIntegrity is set to 0.

Assignment Filters – Limit Attachment of Assignments to Specific Computers

You can now limit the delivery of application packages to specific computers by appending the computer’s name to set application assignments. This prevents packages from attaching when users login to an unsupported desktop pool. Note that this is not available when assigning directly to a computer object.

Support was added for:

Microsoft Office 2019
Microsoft SQL Server 2019
Microsoft Windows 10, version 2004

Rolling Upgrades

Rolling upgrades are now supported, meaning you can upgrade from one version of App Volumes to the next with no downtime. You can also update one sever at a time while others continue running. For more information, see App Volumes Installation Guide.

Tech Preview - MSIX App Attach Integration

This release gives you an early-access tech preview of new packaging options and wider format support. App Volumes Manager enables packagers to use the same lifecycle and assignment marker features with different package formats, side-by-side. The App Volumes agent can leverage Microsoft’s native app to attach functions alongside its own App Volumes virtualization format. See the App Volumes Packaging Utility fling, which helps package applications and supplements the VHD with the required metadata before importing.

For more information, see VMware App Volumes 4, version 2006 Release Notes.

VMware Dynamic Environment Manager

A number of new features and enhancements come with the latest release of VMware Dynamic Environment Manager.

Editions

New editions are now available: Standard and Enterprise. The Standard edition is available to you if you have new or existing Horizon Standard and Advanced deployments. If you have a Horizon 7.x deployment with current SNS, you will receive DEM Standard with Horizon 8. To learn how to migrate from legacy solutions to modern solutions in detail, see Modernizing VDI for a New Horizon. https://techzone.vmware.com/resource/modernizing-vdi-new-horizon , including scripts to help you automate the process of migration.

Standard Feature List

The standard feature list includes complete personalization, complete condition sets, application profiler, and helpdesk support tool, as well as limited user environment, such as:

Drive Mappings
Folder Redirection
Logon Tasks
Logoff Tasks
Printer Mappings

Privilege Elevation Enhancement

In this feature walk-through, you will see how the privilege elevation feature of Dynamic Environment Manager has been enhanced to run elevated tasks. You have had privilege elevation for executables and application installers in past releases. This release brings a new privilege elevation type, called elevated task. You can use elevated tasks to elevate privileges during login, logoff, session reconnect, and so on. Find out more about how this new feature works:

Manage ADMX Settings

You can use Dynamic Environment Manager to manage user and computer-based ADMX policies without the need for group policy options. You have been able to manage user-based templates in the past, but now computer-based templates are available as well. This streamlines your job by reducing the number of consoles to manage. You have granular control of policy application. Find out more about the benefits and use of this feature:

For more information, see Dynamic Environment Manager – Manage Com

VMware Unified Access Gateway 3.10 - Great Reference

2020-09-28T08:11:00.002-05:00

Overview

Info Provided by: https://www.carlstalhood.com/vmware-unified-access-gateway/

Unified Access Gateway provides remote connectivity to internal Horizon Agent machines. For an explanation of how this works (i.e. traffic flow), see Understanding Horizon Connections at VMware Tech Zone.

Unified Access Gateway (formerly known as Access Point) is a replacement for Horizon Security Servers. Advantages include:

You don’t need to build extra Connection Servers just for pairing. However, you might want extra Horizon Connection Servers so you can filter pools based on tags.
Between Unified Access Gateway and Horizon Connection Servers you only need TCP 443. No need for IPSec or 4001 or the other ports. You still need 4172, 22443, etc. to the View Agents.
No need to enable Gateway/Tunnel on the internal Horizon Connection Servers.
Additional security with DMZ authentication. Some of the Authentication methods supported on Unified Access Gateway are RSA SecurID, RADIUS, CAC/certificates, etc.

However:

It’s Linux. You can deploy and configure the appliance without any Linux skills. But you might need some Linux skills during troubleshooting.

Horizon View Security Server is still developed and supported so you’re welcome to use that instead of Unified Access Gateway. But some of the newer Blast Extreme functionality only works in Unified Access Gateway (Access Point) 2.9 and newer. See Configure the Blast Secure Gateway at VMware Docs.

More information at VMware Blog Post Technical Introduction to VMware Unified Access Gateway for Horizon Secure Remote Access.

Horizon Compatibility – Refer to the interoperability matrix to determine which version of Unified Access Gateway is compatible with your version of Horizon.

UAG version 3.7 is UAG ESB for Horizon 7.10 ESB.

UAG version 3.3.1.0 is UAG ESB for Horizon 7.5.2 ESB.

Download one of the following versions of UAG:

For Horizon 7.12, download Unified Access Gateway (UAG) 3.10 for vSphere and Amazon AWS (Non-FIPS).
For Horizon 7.10 (ESB), download Unified Access Gateway 3.7 for vSphere and Amazon AWS. You usually want the non-FIPS version.
For Horizon 7.5.2 (ESB), download Unified Access Gateway 3.3.1.0 (ESB). You usually want the non-fips version.

Then download the PowerShell deployment scripts on the same UAG download page.

Firewall

VMware Technical White Paper Blast Extreme Display Protocol in Horizon 7, and Firewall Rules for DMZ-Based Unified Access Gateway Appliances at VMware Docs.

Open these ports from any device on the Internet to the Unified Access Gateway Load Balancer VIP:

TCP and UDP 443
TCP and UDP 4172. UDP 4172 must be opened in both directions. (PCoIP)
TCP and UDP 8443 (for HTML Blast)

Open these ports from the Unified Access Gateways to internal:

TCP 443 to internal Connection Servers (through a load balancer)
TCP and UDP 4172 (PCoIP) to all internal Horizon View Agents. UDP 4172 must be opened in both directions.
TCP 32111 (USB Redirection) to all internal Horizon View Agents.
TCP and UDP 22443 (Blast Extreme) to all internal Horizon View Agents.
TCP 9427 (MMR and CDR) to all internal Horizon View Agents.

Open these ports from any internal administrator workstations to the Unified Access Gateway appliance IPs:

TCP 9443 (REST API)
TCP 80/443 (Edge Gateway)

Network Profile

Note: in Unified Access Gateway 3.3 and later, Network Protocol Profile is no longer necessary and you can skip this section.

Before importing the Unified Access Gateway OVF, you will need to configure a Network Profile. In vSphere Web Client, go to the Datacenter object. On the right, switch to the Manage (or Configure) tab > Network Protocol Profiles.
Click the plus icon.
In the Select name and network page, enter a name, select the DMZ VM Network for your Unified Access Gateway appliance, and click Next.
In the Configure IPv4 page, enter the subnet information, and Gateway.
Don’t configure an IP pool. Click Next.
In the Ready to complete page, click Finish.
If you are configuring multiple NICs on your Unified Access Gateway, create Network Protocol Profile for the remaining subnets.

Install an SSL Certificate on VMWare Horizon View

2020-09-28T08:05:00.000-05:00

Install an SSL Certificate on VMWare Horizon View

After the CA signs your SSL Certificate, it will send all the necessary installation files to your email inbox. You need to download the ZIP folder and extract the SSL files.

To import your certificates into the Windows Certificate store, please follow the instructions below:

Log into your Connection/Security server and launch mmc.exe
Navigate to File > Add/Remove Snap-in and select Certificates then hit Add
In the Certificates snap-in window select Computer Account, then Next
Scroll down to Certificates/Personal/Certificates and under Friendly Name column, look for vdm
Right-click the vdm certificate and go to Properties
In the General Tab, rename the Friendly Name from vdm into vdm-original, then click Apply and OK
After you’ve changed the Friendly Name, right-click anywhere in the Console1 main section and select All Tasks > Import…
In the Certificate Import Wizard browse the certificate file you want to import and hit Next
In the next window, enter the password for your Private Key, and check Mark this key as exportable and Include all extended properties boxes. Click Next
In the next Window, click Next, then Finish
Locate the newly imported certificate and right-click it. Select Properties, change the Friendly Name into vdm, then hit Apply > OK
Restart your server to complete the SSL installation.

Congratulations, you’ve successfully added a new SSL Certificate to VMware Horizon View.

Test your SSL Installation

After you install an SSL Certificate on VMWare Horizon View, grab one of these highly rated SSL tools and run a diagnostic scan on your SSL configuration. In just a few seconds, the SSL tool will pinpoint all the existing vulnerabilities and potential errors.

VMWare Horizon View history and versions

VMware Horizon View is a commercial desktop virtualization product developed by VMware, Inc. Initially, it was sold under the name VMware VDM, then changed to VMware View, and, finally Horizon View with the release of version 6 in April 2014.

Listed below are the latest VMWare Horizon releases:

VMware Horizon 7.6 (Sep 6, 2018)
VMware Horizon 7.5.1 (July 19, 2018)
VMware Horizon 7.5 (May 29, 2018)
VMware Horizon 7.4 (Jan 04, 2018)
VMware Horizon 7.3.2 (November 20, 2017)
VMware Horizon 7.2 (Jun 20, 2017)
VMware Horizon 7.1 (March 16, 2017)
VMware Horizon 7.0.3 (December 8, 2016)
VMware Horizon 7.0.2 (September 15, 2016)
VMware Horizon 7.0.1 (June 16, 2016)

2019-07-24T11:44:00.002-05:00

Recently I have ran across random file deletions and on terminal services on Windows 2012 R2+ servers. Typically this is automated A/V programs, pre-crypto programs being installed and blocked and even end users just hacking around. This is a great procedure to setup to track and be proactive on file manipulation on Terminal Server management for Windows Servers

File Access Auditing Event IDs

Once you configured above two settings, now you can see the actual events, to view the file access and file change events, follow the below steps.
1. Open the Run window, type the command eventvwr.msc, and click OK.

2. You can see the Event Viewer Management Console, expand the tree node Windows Logs and select Security.

3. Now, you can see lot of events in right-hand side window, but to track file access, we need to check only two event ids, 4656 and 4663. To filter only these two events, right-click on the Security node and click Filter Current Log.
4. Type the event ids 4656 and 4663 as comma separated values and click.

5. Now, result window lists only file access events, you can double-click on any event and check what type action made on the particular file.

4656: This is the first event logged when an user attempts to access the file, this event gives information about what type of access was requested by the user and it will not give info about what type access actually made by user (which is given by the Event ID 4663).
4663: This event gives the info of what type actual operation is done by user on a file. it tells whether the file was created, modified, deleted, or it simply accessed,
4670: This event logged when user changes the permission of the file (security control list). The event contains the information, who changed the permissions, old and new permissions.
Event 4663 - Delete File Event Source:

WIndows 10 Prep - Disable First Run "hi" on Base Image

2019-07-15T11:39:00.003-05:00

In the right panel, find the Show first sign-in animation value and double-click it. Set it to Disabled to prevent the animation from showing. Note that this will also prevent Windows from asking new Microsoft Account users to opt-in to various Microsoft services at first run.

Windows 10 Home users will have to use the Registry to hide the animation. Type regedit into the Start Menu to open the Registry Editor. Then browse to this value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Once you’ve opened the System folder, right-click on the right panel and choose New > DWORD (32-bit Value). Give it the name EnableFirstLogonAnimation, then double-click it to change its value. Make sure it’s set to 0 to hide the animation.

Done.....

VMware View Composer Error. Timeout waited (0) seconds error (6) Fix for Horizon View 7.0-7.4

2019-07-09T12:42:00.000-05:00

So with Horizon View 7.0 and until Windows 10 1709 is fully support you will need this fix to resolve the "VMware View Composer Error. Timeout waited (0) seconds error (6)"

Open regedit and delete the “Security” subkey in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE

So, delete HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Security

Also, under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE there should be an entry for “DependOnService” with a value of “RpcSs and vmware-viewcomposer-ga”, remove “vmware-viewcomposer-ga”.

Take new snapshot to base image and Recompose and you should be good.

HVE ConneXions Improves Virtualization Environments - Healthchecks, Upgrades, New Installations

2019-06-06T07:55:00.000-05:00

www.hveconnexions.com
info@hveconnexions.com

VMWare Horizon View Persona Management - Extremly Long/Slow Logoff in Windows 10

2019-06-05T16:18:00.001-05:00

With Windows 10 and Persona Management there are several issues that are arising and recommendations are to use UEM. However, several customers cannot afford the upgrade nor have the time to change the complete environment. First I recommend Windows 10 Build 1709. Then below are a couple of links and some procedures that can help out.

Notes:

Windows 10 and 5-10 Minute logoff issues with VMWare. Now this occurs on 7.3.2+ builds with Windows 10 (all builds) and the registry and GPO Policy needs to be applied.

Please ensure this is applied to Persona environment. This issue has been a real pain to resolve but with Floating pools and Persona management this must be applied to all accounts. Tested and is working great!!!

                WaitToKillServiceTimeout
                https://technet.microsoft.com/en-us/library/cc976045.aspx

                WaitToKillAppTimeout
                 https://technet.microsoft.com/en-us/library/cc978624.aspx

                HungAppTimeout
                https://technet.microsoft.com/en-us/library/cc978614.aspx

                AutoEndTasks
                https://technet.microsoft.com/en-us/library/cc978604.aspx

[HKEY_CURRENT_USER\Control Panel\Desktop] "AutoEndTasks"="1"
[HKEY_USERS\.DEFAULT\Control Panel\Desktop] “AutoEndTasks”=”1"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control] -- “WaitToKillServiceTimeout”=”1000″

Then Enable this policy within the Persona GPO

Some helpful links:

https://kb.vmware.com/s/article/2016416

https://communities.vmware.com/thread/578690

https://www.simonlong.co.uk/blog/vmware-view-persona-management/