VMware vSphere ESX and vCenter Configuration Maximums

Virtual Machine Maximums

 ESX 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5ESX 4.1ESX 4.0ESX 3.5ESX 3ESX 2ESX 1
Virtual CPUs per virtual machine256128128128646432884421
RAM per virtual machine6128 GB6128 GB6128 GB4TB1TB1TB1TB255GB255GB65GB16GB3,6GB2GB
Virtual SCSI adapters per virtual machine4444444444444
Virtual SCSI targets per virtual SCSI adapter1515151515
Virtual SCSI targets per virtual machine6060606060
Virtual NVMe adapters per virtual machine444
Virtual NVMe targets per virtual SCSI
Virtual NVMe targets per virtual machine606060
Virtual SATA adapters per virtual machine44444
Virtual SATA devices per virtual SATA adapter3030303030
Virtual disk size62TB62TB62TB62TB62TB2TB2TB2TB2TB2TB2TB
IDE controllers per virtual machine1111111111
IDE devices per virtual machine4444444444
Floppy controllers per virtual machine111111111111
Floppy devices per virtual machine222222222222
Virtual NICs per virtual machine1010101010101010104444
USB controllers per virtual machine11111111
USB devices connected to a virtual machine2020202020202020
Serial ports per virtual machine3232323232323232
Parallel ports per virtual machine333333333331
Concurrent remote console connections4040404040404040401010
Video memory per virtual machine4 GB2 GB2 GB512MB512MB
NVDIMM controllers per VM11
NVDIMM devices per VM6464
Non-volatile memory per VM6128 GB6128 GB

Host Maximums

 ESX 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5ESX 4.1ESX 4.0ESX 3.5ESX 3ESX 2ESX 1
Logical CPUs per host768768576480320160160160643232168
Virtual machines per host10241024102410245125125123203201281288064
Virtual CPUs per host40964096409640964096204820485125121281288064
Virtual CPUs per core3232323232252525208888
RAM per host16TB16TB12TB12TB4TB2TB2TB1TB1TB256GB256GB64GB64GB
LUNs per server10241024512256256256256256256
Non-volatile memory per host12TB1TB

vCenter Server Maximums

vCenter Server MaximumsvC 7.0vC 6.7vC 6.5vC 6.0vC 5.5vC 5.1vC 5vC 4.1vC 4.0vC 3.5vC 3
Hosts per vCenter Server25002000200010001000100010001000300200200
Powered on virtual machines400002500025000100001000010000100001000030002000
Registered virtual machines450003500035000150001500015000150001500045002000
Linked vCenter Servers151515101010101010
Hosts in linked vCenter Servers1500050004000400030003000300030001000
Powered on virtual machines in linked vCenter1350005000030000300003000030000300003000010000
Registered virtual machines in linked vCenter1500007000050000500005000050000500005000015000
Number of host per datacenterN/A20002000500500500500400100
MAC addresses per vCenter Server65536655366553665536655366553665536
USB devices connected at vSphere ClientN/AN/AN/A20202020

Cluster and Resource Pool Maximums

 ESXi 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5ESX 4.1ESX 4.0ESX 3.5
Hosts per cluster64646464323232323232
Virtual machines per cluster800080008000400040004000300030001280
Virtual machines per host1024102410241024512512512320100
Resource pools per cluster1600160016001600160016001600512512128
Resource pools per host16001600160016001600160016004096
Children per resource pool16001600160016001024102410241024
Resource pool tree depth888888881212

Network Maximums

 ESX 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5ESX 4.1ESX 4.0ESX 3.5ESX 3
Total virtual network switch ports per host409640964096409640964096409640964096127
Maximum active ports per host1016101610161016101610501016101610161016
Virtual network switch creation ports408840884088408840884088408840884088
Port groups512512512512512256256512512512
Distributed virtual network switch ports per vCenter60000600006000060000600006000030000200006000
Static port groups per vCenter10000100001000010000100001000050005000512
Ephemeral port groups per vCenter101610161016101610162562561016
Hosts per distributed switch200020002000100050050035035064
Distributed switches per vCenter128128128128128128323216

Storage Maximums

 ESX 7,0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5ESX 4.1ESX 4.0ESX 3.5ESX 3
Software iSCSI NICs per server88888888
Number of total paths on a server40964096204810241024102410241024
Number of paths to a iSCSI LUN88888888
Software iSCSI targets256256256256256256256256256
NFS mounts per host2562562562562562562566464
FC LUNs per host10241024512256256256256256256256256
FC LUN ID1638316383163831023255255255255255255255
FC Number of paths to a LUN3232323232323232323232
Number of HBAs of any type888888888
HBA ports16161616161616161616
Targets per HBA25625625625625625625625625615
Software FCoE adapters4444444
Volumes per host10241024512256256256256256256256
Hosts per volume64646464646464646432
Powered on virtual machines per VMFS volume2048204820482048204820482048256
Concurrent vMotion operations per datastore128128128128128128128
Concurrent Storage vMotion operations per datastore8888888
Concurrent Storage vMotion operations per host2222222
Concurrent non vMotion provisioning operations per host8888888
VMFS Volume size64TB64TB64TB64TB64TB64TB64TB64TB64TB64TB
Virtual disks per datastore cluster90009000900090009000
Datastores per datastore cluster6464646464
Datastore clusters per vCenter256256256256256

Fault Tolerance Maximums

 ESX 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5ESX 5.1ESX 5.0
Virtual disks161616161616
Virtual CPUs per virtual machine8844111
RAM per FT VM128GB128GB64GB64GB64GB64GB64GB
Virtual machines per host4444444
Disk size2 TB2 TB2 TB2 TB

Virtual SAN Maximums

 ESX 7.0ESX 6.7ESX 6.5ESX 6.0ESX 5.5
Virtual SAN disk groups per host55555
Capacity tier devices per disk group77777
Cache tier devices per disk group11111
Spinning disks in all diskgroups per host3535353535
Components per Virtual SAN host90009000900090003000
Number of Virtual SAN nodes in a cluster6464646432
Number of Virtual SAN nodes in a cluster (All-Flash)643232
Number of datastores per cluster11111
Virtual machines per host200200200200100
Virtual machines per cluster64006000600064003200
Virtual machine virtual disk size62TB62TB62TB62TB2032GB
Disk stripes per object1212121212
Percentage of flash read cache reservation100100100100100
Percentage of object space reservation100100100100100
Virtual SAN networks/physical network fabrics22222

All informations are based on VMware documentation:

VMware P2V Permission to perform this operation was denied fix

This workaround worked for me.

local security policy disabled p2v

Just the other day we had a Windows Server 2008 R2 Standard physical server that needed to be P2V’ed, and after trying to use VMware Converter Standalone 6.1.1 we ran into the error message “Permission to perform this operation was denied” after entering the source machine details.

vmware p2v permission denied

Even after trying to start VMware Converter as “Run as administrator” the error persisted. Below is the workaround we performed to quickly allow us to P2V the physical server.

Workaround for Permission to perform this operation was denied

  1. Log into the server you’re trying to convert to a virtual machine.
  2. Open Local Security Policy (open run dialog and type secpol.msc).
  3. Go to: Local Policies > Security Options.
  4. Change “User Access Control: Run all Administrators in Admin Approval Mode” from Enabled to Disabled.
  5. Restart the server to make the changes take effect.
  6. You should now be able perform the P2V without issue.
VMware P2V completed

After making the above change we was able to successfully P2V the server without any further issues:

local security policy enabled p2v

Once you confirm the P2V is successful I would recommend changing User Access Control: Run all Administrators in Admin Approval Mode back to Enabled from Disabled.

If you have another workaround please share in the comments!

Super Metric to count VMs by Windows or Non-Windows

This super metric is used for publishing dashboard with the count of Windows VMs and Linux VMs within vRA Business Groups .

This super metric may also be applied against any other objects  like Datacenter , Datastore , vCenter etc.

The formula used were as below :

For Count of Windows VMs:

count(${adaptertype=VMWARE, objecttype=VirtualMachine, attribute=summary|guest|fullName, depth=5, where =”summary|guest|fullName startsWith Microsoft Windows”})

For Count of non-Windows VMs:

count(${adaptertype=VMWARE, objecttype=VirtualMachine, attribute=summary|guest|fullName, depth=5, where =”summary|guest|fullName !startsWith Microsoft Windows”})

You may modify this to count any specific OS also by replacing “Microsoft windows” with any other OS name as found from the Virtual Machine Property Summary|Guest Operating System|Guest OS Full Name.

Issue with deploying ISE ova in ESXi 6.7

The OVA can’t be deployed as.. an OVA

Yep. The install file provided by Cisco needs to be converted to a different format in order to work with VMware i.e. OVF.

The error message when attempting this:

3.5: ATTRIBUTE_REQUIRED: Attribute “id” is required.

3.5: ATTRIBUTE_REQUIRED: Attribute “href” is required.

15.3: ATTRIBUTE_REQUIRED: Attribute “id” is required.


To be fair this is partly documented by Cisco but it doesn’t clear much up on what to do next.


The ISE 2.3 OVA templates are not compatible with VMware web client for vCenter 6.5. As a workaround, use the VMware OVF tool to import the OVA templates.

Download VMware OVF Tool


For ISE 2.3 on to ESXi 6.5 I used OVF Tool version 4.2

You can convert directly from OVA to OVF but we encountered the error below after doing this and importing to ESXi. A senior colleague saved my bacon by saying they’d had luck going from OVA to VMX then to OVF.

4:5: PARSE_ERROR: Parse error: Unexpected character ‘.’ (code 58) (missing namespace prefix?) at [row,col,system-id]: [4,11,”descriptor.ovf”].


Convert OVA -> VMX

  1. Install the OVF Tool
  2. Place your OVA somewhere easily accessible (C:) and open up elevated command prompt.
  3. Navigate to cd C:\Program Files\Vmware\Vmware OVF Tool
  4. Initiate the executable in the format ovftool.exe “source file” “destination file” e.g. ovftool.exe “C:\ISE-” “C:\ISE-”
  5. The above will convert from the OVA to the VMX in the same directory of C:

Once complete you will see both the original OVA and the two new VMX/VMDK files


Convert VMX -> OVF

Now that VMX can be converted to OVF. Note you can choose not to use the quotations like in this example as long as there’s a space between source and destination. I created an OVF directory so that it didn’t overwrite any files during this process.

ovftool.exe C:\ISE- C:\OVF\ISE-

You will end up with three files in your OVF directory and the OVF can be used for the import to ESXi.

Import to ESXi

This time there is no error on the import and the resources are automatically filled out via the OVF template.


VMware Workstation Device/Credential Guard are not compatible

VMware Workstation Device/Credential Guard are not compatible

When using VMware Workstation 15 Pro with on Windows 10 with the Hyper-V role enabled I’ve got the following error when trying to install or start Windows 10 in VMware Workstation:

VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential Guard. Please visit http://www.vmware.com/go/turnoff_CG_DG for more details.


VMwar Workstatin error

In 2013 I did a post about using VMware Workstation and Hyper-V together on Windows 8, link. The bottom line that the Hyper-V role conflicts with  VMware Workstation.  It looks like this is still the case. The same  solution can be used to  disable the Hyper-V role in Windows 10.

To disable Hyper-V from starting the following command can be used:

bcdedit /set hypervisorlaunchtype off

A reboot of Windows 10 is necessary. After the reboot I was able to boot the Windows 10 VM.


To enable the Hyper-V role again use the following command:

bcdedit /set hypervisorlaunchtype auto

A reboot of of the Windows 10 is necessary.





Post source : jortechnologies

Adding a Nutanix Network Share as a Datastore in VMware ESXi

Sharing NFS containers on your current VMware vSphere environment becomes quite a routine while getting used to your new Hyper-Converged infrastructure “Nutanix”, for the purposes of this guide you will learn how to easily mount Nutanix NFS containers as VMware NFS Datastores.

First of all, make sure to create a storage container in order to designate it as the NFS Datastore that will be later used for you VMware ESXi, I have named mine VMware-NFS

Storage -> Table -> + Storage Container


For security matter, we need to tell Nutanix to give access from the ESXi host to mount the NFS share, in order to do so we must click on the Gear icon and then click on Filesystem Whitelists.

Add your’s server IP/Netmask and this will grant you access to the NFS shares.


Time to move to our VMware vSphere ESXi Host, since VMware has started to push everyone to leave the windows client and start using the web client this guide will be performed on the Web Client, Thanks VMware!!!

Once logged in click on Storage on the left side.


There we will see the datastores list, since this a fresh installation we only have the default datastore, in order to add our Nutanix container as NFS datastore we must click on the New datastore option. The New Datastore wizard will pop up, select the Mount NFS datastore option and click next.


Fill the information requested:

Name: Nutanix NFS  – You can use whatever name you want

NFS Server: – This is my Nutanix’s Cluster Virtual IP

NFS Share:/VMware-NFS – Storage’s Container name

NFS Version NFS-3 or NFS-4 you can choose base on your experience and performance obtained.

Our configuration will look pretty much like this:

Once everything is set click on Finish

How vCenter Assigns MAC Address to VMware Virtual Machine?

Post Source : Thanks to vmwarearena

How vCenter Assigns MAC Address to VMware Virtual Machine?


I have been asked by many VMware Administrators about how MAC addresses are assigned to Virtual Machine?. We all aware that first 3 octets will be 00:50:56. The first three parts never change. This is the VMware Organizational Unique Identifier (OUI). How do other 3 octets are generated?. This may be the biggest question in our mind? Let’s discuss How MAC addresses are assigned to VMware  Virtual Machines by the vCenter Server. This post only applies to the VM MAC generation, in which ESXi host is managed by vCenter Server. ESXi host which is not managed by the vCenter server will have the different mechanism to generate the MAC address for Virtual Machine.

How vCenter Assigns Virtual MAC Address to VMware Virtual Machine?

As we aware that, First 3 Octects will be 00:50:56. This is the VMware Organizational Unique Identifier (OUI). How does 4th  octet of VM MAC address are calculated? Let’s begin the Calculation.

4th Octet of MAC = (128+ vCenter Instance ID) Convert it to Hexadecimal

To get the vCenter Server Instance ID -> Login to vSphere Client ->Administration -> vCenter Server Settings -> Runtime Settings. Note down the vCenter Server Unique ID. My vCenter Server Unique ID is 31.

vCenter 6.5


How to Calculate 4th Octet of the VM MAC Address?

The automatically generated MAC address has the fourth octet is equal to 128 + the vCenter instance ID converted to hexadecimal.

4th Octet of MAC = (128+ vCenter Instance ID) Convert it to Hexadecimal

= 128+31 = 159



4th Octet of VM MAC = 9f (Conversion of 159 to Hexadecimal)

I have confirmed the Same from the few of Virtual Machine MAC Address. 4 octet is assigned as “9f”.




The last two bytes are assigned in the mechanism so that each MAC address is assigned would be unique. I hope this is informative for you. Thanks for Reading!!!. Be Social and share it on social media, if you feel worth sharing it.


Migrate On-Premises Virtual Machines to AWS

Post source – Star Wind


AWS Server Migration Server (SMS) allows the migration of one or multiple on-premises virtual machines to AWS in an easy way from a single pane of glass.

The SMS service allows to schedule and automate replications needed to easily manage server migrations.


Setup the environment

Before deploying the required components to migrate virtual machines to AWS, both AWS and vSphere environments must be configured accordingly. Four main steps are required to complete the procedure:

  • Download the AWS Server Migration Service appliance
  • Create a IAM user in AWS used by the connector
  • Configure a user and the role in vCenter Server used by the SMS appliance
  • Deploy and configure the SMS appliance

Create an AWS user and grant permissions

To migrate virtual machines to AWS, you need to create a new IAM user used by the Server Migration Connector to communicate with AWS.

First login to the AWS console.


From the AWS console select IAM under Security, Identity & Compliance section to create a new user.


Select Users tab and click Add.


Specify the User name and select Programmatic access option. Click Next.


Select Add user to group tab then click Create group. Specify a Group Name and select the ServiceMigrationService policy then click Create group.


Click Create user.


When the user has been created successfully, write down the Access key ID and the Secret access key then click Close.


Attach the AWS Server Migration Service role to the created user. Following this guide to create the required role.


Configure a new user and role in vCenter Server

To grant the correct permissions to the account used by the Connector, from the vSphere Client click Menu and select Administration to access the Roles management area.


Select the Read-only role and click on clone icon.


Enter the Role name and a Description then click OK.


Select the just created role from the list and click the edit icon.


Assign the following permissions to the selected role and click Next when done:

  • Datastore > Browse datastore and Low level file operations
  • vApp > Export
  • Virtual Machine > Snapshot management > Create snapshot and Remove Snapshot
  • Host > Config > System Management


Click Finish to save the configuration.


Permissions assigned to the new role.


To apply permissions to vCenter Server’s objects, select the vCenter Server to process and go to the Permissions tab. Click on plus icon and specify the User and the Role to use. Enable Propagate to children option then click OK.


Deploy the Server Migration Connector appliance

Access the AWS portal and login with your account.


Select Server Migration Service under Migration.


From the AWS Server Migration Service page click Get Started button.


Click Download OVA to download the required vCenter format of the Server Migration Connector appliance.


When the download has completed, from vSphere Client right click the cluster/resource pool where to install the appliance and select Deploy OVF Template option.


Click Choose Files and select the AWS-SMS-Connector.ova file just downloaded from AWS. Click Next.


Specify the Virtual machine name and select a folder then click Next.


Select the compute resource then click Next.


Click Next to continue.


Specify the virtual disk format and the datastore to store the appliance. Click Next to continue.


Specify the correct Destination Network to use then click Next.


Click Finish to deploy the appliance.


When the appliance has been deployed successfully, right click the VM and select Power > Power On.


Configure the SMS appliance

From the SMS appliance’s Summary tab, note the IP address assigned to the SMS by the DHCP. By default the SMS appliance is configured to get the IP address via DHCP.


Open your favorite browser and type the address https://SMSappliance_IP_Address. Click Get started now button.


Accept the EULA and click Next.


Enter a New password and click Next.


Follow the instructions if you want to configure a static IP address then click Next. The default SMS credentials are the following:

Username: ec2-user
Password: ec2pass

Login to the appliance’s console and run the following command to configure network settings:

In the example a static IP address has been configured.


Select Automatically upgrade the AWS connector when new versions are available to keep the appliance always up-to-date. Click Next.


Choose the Region for SMS and enter the Access key and the Secret key of the IAM account previously created. Click Next.


Specify the vCenter Host Name and Username/Password of the account used to connect the vCenter Server. Click Next.


Click Trust to validate the certificate.


The SMS Connector has been configured successfully. Click on Go to connector dashboard button.


The SMS Connector dashboard.


Import the server catalog

From the AWS console, click on Server Migration Service under the Migration section.


Go to Connectors tab and click Import server catalog to create a list of VMs in the specified vCenter Server.


Click Import to proceed.


When the import procedure has completed, a list of virtual machines currently running in the vCenter Server is displayed.

VSAN from StarWind eliminates any need for physical shared storage just by mirroring internal flash and storage resources between hypervisor servers. Furthermore, the solution can be run on the off-the-shelf hardware. Such design allows VSAN from StarWind to not only achieve high performance and efficient hardware utilization but also reduce operational and capital expenses.
Learn more about ➡ VSAN from StarWind

Migrate virtual machines to AWS

When the import process has completed, from the Servers tab select the virtual machines you want to replicate to AWS. Click Create replication job.


Specify the License type then click Next. Available license types are the following:

  • Auto – the source OS is detected and the appropriate license is applied to the migrated VM
  • AWS – an aws license is assigned to the migrated VM if appropriated
  • BYOL – the source-system license is retained on the migrated VM if appropriated


Configure replication settings and specify the IAM service role to use created at the beginning of the procedure. Click Next.


Click Create to replicate the selected VM to AWS.


The configured replication job begins. Click View replication jobs button to see replicated VMs.


Replication details can be displayed by selecting the active replica.


When the migration has completed successfully, an AMI ID is created. Select the migrated VM and click on Actions > Launch instance from latest AMI to run the VM.


The VM can be launched also from the EC2 dashboard in the Images > AMIs section.

Using this procedure, the migration of multiple on-premises virtual machines to AWS can be performed in an easy way.

How to migrate your on-premises domain to AWS Managed Microsoft AD using ADMT

Post Source – Danny Jenkins |
Customers often ask me how to migrate their on-premises Active Directory (AD) domain to AWS so they can be free of the operational management of their AD infrastructure. Frequently they are unsure how to make the migration easy. A common approach using the CSVDE utility doesn’t migrate attributes such as user passwords. This makes migration difficult and necessitates manual effort for a large part of the migration that can cause operational and security challenges when migrating to a new directory. So what’s changed?

You can now use the Active Directory Migration Toolkit (ADMT) along with the Password Export Service (PES) to migrate your self-managed AD to AWS Directory Service for Microsoft Active Directory, also known as AWS Managed Microsoft AD. This enables you to migrate AD objects and encrypted passwords for your users more easily.

AWS Managed Microsoft AD, a managed service built on actual Microsoft Active Directory. AWS provides operational management of the domain controllers and you use standard AD tools to administer users, groups, and computers. AWS Managed Microsoft AD enables you to take advantage of built-in Active Directory features, such as Group Policy, trusts, and single sign-on and helps make it easy to migrate AD-dependent workloads into the AWS Cloud. With AWS Managed Microsoft AD, you can join Amazon EC2 and Amazon RDS for SQL Server instances to a domain, and use AWS Enterprise IT applications, such as Amazon WorkSpaces, and AWS SSO with Active Directory users and groups.

In this blog, I will show you how to migrate your existing AD objects to AWS Managed Microsoft AD. The source of the objects can be your self-managed AD running on EC2, on-premises, co-located, or even another cloud provider. I will show how to use ADMT and PES to migrate objects including users (and their passwords), groups, and computers.

The blog post assumes you are familiar with AD and how to use the Remote Desktop Protocol client to sign and use EC2 Windows instances.


In this post I will migrate user and computer objects, as well as passwords, to a new AWS Managed Microsoft AD directory. The source will be an on-premises domain.

This example migration will be for a fairly simple use case. Large customers with complex source domains or forests may have more complex processes involved to map users, groups, and computers to the single OU structure of AWS Managed Microsoft AD. For example, you may want to migrate an OU at a time. Customers with single domain forests may be able to migrate in fewer steps. Similarly, the options you might select in ADMT will vary based on what you are trying to accomplish.

To perform the migration, I will use the admin user account from my AWS Managed Microsoft AD. AWS creates the admin user account and delegates administrative permissions to the account for an organizational unit (OU) in the AWS Managed Microsoft AD domain. This account has most of the permissions required to manage your domain, and all the permissions required to complete this migration.

In this example, I have a Source domain called source.local that’s running in a network range, and I want to migrate my users, groups, and computers to a destination domain in AWS Managed Microsoft AD called destination.local that’s running in a network range of

To migrate users from source.local to destination.local, I need a migration computer that I join to the destination.local domain on which I will run ADMT. I also use this machine to perform administrative tasks on my AWS Managed Microsoft AD. As a prerequisite for ADMT, I must install Microsoft SQL Express 2016 on the migration computer. I also need an administrative account that has permissions in both the source and destination AD domains. To do this, I will use an AD trust and will add my AWS Managed Microsoft AD admin account from destination.local to my source.local domain. Next I will install ADMT on the migration computer, and will run the PES on one of the source.local domain controllers. Finally, I will migrate the users and computers.

For this example, I have a handful of users, groups, and computers, shown in the source domain in these screen shots, that I will migrate:
Figure 1: Example source users

Figure 2: Example client computers

In the remainder of this blog, I will show you how to do the migration in 5 main steps:

  1. Prepare the forests, migration computer, and administrative account.
  2. Install SQL Express and ADMT on the migration computer.
  3. Configure ADMT and PES.
  4. Migrate users and groups.
  5. Migrate computers.

Step 1: Prepare the forests, migration computer, and administrative account

To migrate users and passwords from the source domain to AWS Managed Microsoft AD, you must have a 2-way forest trust. The trust from the source domain to AWS Managed Microsoft AD enables you to add the admin account from the AWS Managed Microsoft AD to the source domain. This is necessary so you can grant the AWS Managed Microsoft AD admin account permissions in your source AD directory so it can read the attributes to migrate. I’ve already created a two-way forest trust between these domains. You should do the same by following this guide. Once your trust has been created, it should show up in the AWS console as Verified.

The ADMT tool should be installed on a computer that isn’t the domain controller in the destination domain destination.local. For this, I will launch an EC2 instance in the same VPC as my domain controller and I will add it to the destination.local domain using the EC2 seamless domain join feature. This will act as my ADMT transfer machine.

  1. Launch a Microsoft Windows 2012 R2 instance.
  2. Complete a domain join to the target domain destination.local. You can complete this manually, or alternatively you can use AWS Systems Manager to complete a seamless domain join as covered here.
  3. Sign into the instance using RDP and use Active Directory Users and Computers (ADUC) to add the AWS Managed Microsoft AD admin user from the destination.local domain to the source.local domain’s built-in administrators group (you will not be able to add the admin user as a domain admin). For information on how to set up this instance to use ADUC, please see this documentation.

    Figure 3: the "Administrator's Propoerties" dialog box

Step 2: Install SQL Express and ADMT on the migration computer

Next, I need to install SQL Express and ADMT on the migration computer by following these steps.

  1. Install Microsoft SQL Express 2016 on this computer with a default install.
  2. Download ADMT version 3.2 from the Microsoft website.
  3. Once it has downloaded, run the installer and, when setting the tool up, on the Database Selection page of the wizard, for Database (Server\Instance), type the local instance of Microsoft SQL Express we previously installed to work with ADMT.

    Figure 4: Specify the "Database (Server\Instance)"

  4. On the Database Import page of the wizard, select No, do not import data from an existing database (Default).

    Figure 5: The "Database Import" dialog box

  5. Complete the rest of the installation using all of the default options.

Step 3: Configure ADMT and PES

I’ll use PES to take care of encrypted password synchronization, but before I configure that, I need to create an encryption key that will be used during this process to encrypt the password migration.

  1. On the ADMT transfer machine, open an elevated Command Prompt and use the following format to create the encryption key.

    admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*}

    Here’s an example:

    admt key /option:create /sourcedomain:source.local /keyfile:c:\ /keypassword:password123

    Note: If you get an error stating that the command is not found, close and reopen Command Prompt to refresh the path locations to the ADMT executable, and then try again.

  2. Now, I can download and start the install for the Password Export Server.
  3. Start the install and, in the ADMT Password Migration DLL Setup window, browse to the encryption file you created in the previous step.
  4. When prompted, enter the password used in the ADMT encryption command.
  5. Run PES using the local system account. Note that this will prompt a restart of the domain controller you’re installing PES on.
  6. Once the domain controller has rebooted, open services.msc and start the Password Export Server Service, which is currently set to Manual. You might choose to set this to automatic if it’s likely your DC will be rebooted again before the end of your migration.

    Figure 6: Start the Password Export Server Service

  7. You can now open the Active Directory Migration Tool: Control Panel > System and Security > Administrative Tools > Active Directory Migration Tool.
  8. Right-click Active Directory Migration Tool to see the migration options:

    Figure 7: List of migration options

Step 4: Migrate users and groups

  1. In the Domain Selection page, select or type the Source and Target domains, and then select Next.
  2. On the User Selection page, select the users to migrate. You can use an include file if you have a large domain. Select Next.
  3. On the Organizational Unit Selection page, select the destination OU that you want to migrate your users across to, and then select Next. AWS Managed Microsoft AD gives you a managed OU where you can create your OU tree structure.In this example, I will place them in Users OU:


  4. On the Password Options page, select Migrate passwords, and then select Next. This will contact PES running on the source domain controller.
  5. On the Account Transitions Page, decide how to handle the migration of user objects. In this example, I’m going to replicate the state from the source domain. Migrating SID history is beneficial when you’re doing long, staged migrations where users may need to access resources in the source and destination domain before migration is complete. At this time, AWS Managed Microsoft AD doesn’t support migrating user SIDs. I select Target same as source, and then select Next. Again, what you choose to do might be different.

    Figure 8: The "Account Transition Options" dialog

  6. Now, let’s customize the transfer. The following screen shot shows the commonly selected options on the User Options page of the User Account Migration Wizard:

    Figure 9: Common user options, including "Update user rights," "Migrate associated user groups," and "Fix users' group memberships

It’s likely you’ll have more than one migration pass, so choosing how you handle existing objects is important. This will be a single run for us, but the default behavior is to not migrate if the object already exists (see the image of the Conflict Management page below). If you’re running multiple passes, you’ll will want to look at options that involve merging conflicting objects. The method you select will depend on your use case. If you don’t know where to start, read this article.
Figure 10: The "Conflict Management" dialog box with the "Do not migrate source object..." option selected

In my example, you can see my 3 users, and any groups they were members of, have been migrated.
Figure 11: The "Migration Progress" window

We can verify this by checking the users exist in our destination.local domain:
Figure 12: Checking the users exist in the destination.local domain

Step 5: Migrate computers

Now, I’ll move on to computer objects.

  1. Open the Active Directory Migration Tool: Control Panel > System and Security > Administrative Tools > Active Directory Migration Tool.
  2. Right-click Active Directory Migration Tool and select Computer Migration Wizard.
  3. Select the computers you want to migrate to the new domain. I’ll select four computers for migration.

    Figure 13: Four computers that will be migrated

  4. On the Translate Objects page, select which access controls you want to reapply during the migration, and then select Next.

    Figure 14: The "Translate Objects" dialog box
    The migration process will quickly show completed, but we need to make sure the entire process worked.

  5. To verify the migration was successful, select Close, and the migration tool will open a new window that has a link to the migration log. Check the log file to see that it has started the process of migrating these four computers:
    2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-56SQFFFJCR1.source.local

    2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-IG2V2NAN1MU.source.local

    2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-QKQEJHUEV27.source.local

    2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-SE98KE4Q9CR.source.local

    If the admin user doesn’t have access to the C$ or admin$ share on the computer in the source domain share, then then installation of the agent will fail as shown here:
    2017-08-11 04:09:29 ERR2:7006 Failed to install agent on \\WIN-IG2V2NAN1MU.source.local, rc=5 Access is denied.

    Once the agent is installed, it will perform a domain disjoin from source.local and perform a join to desintation.local. The log file will update when this has been successful:
    2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-SE98KE4Q9CR.source.local’. The new computer name is ‘WIN-SE98KE4Q9CR.destination.local’.

    2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-QKQEJHUEV27.source.local’. The new computer name is ‘WIN-QKQEJHUEV27.destination.local’.

    2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-56SQFFFJCR1.source.local’. The new computer name is ‘WIN-56SQFFFJCR1.destination.local’.

    You can then view the new computer objects in the destination domain.

  6. Log in to one of the old source.localsource.local computers and, by looking at the computer’s System Properties, confirm that the computer is now a member of the new destination.local domain.

    Figure 15: Confirm the computer is member of the destination.local domain

How to migrate a VMware virtual machine to AWS

Post source : Miketabor

Migrate VMware VM's to AWS

At work we’ve been toying with the idea of moving some of our VMware workload off to AWS and I’ve been tasked with migrating a couple VMware virtual machines to AWS as a proof of concept for the time being.

In this post I’ll show how I setup the AWS Connector and did the migration from VMware to AWS using the AWS Server Migration Service.

Migrate vSphere VM to AWS using Server Migration Service

I’m assuming you already have a programmatic access (access key ID and secret access key) IAM account with the ServerMigrationConnector permissions and AWS Server Migration Service role attached, for this demo I’ll be using an account named SMSdemo. If not, go ahead and create that account first.

  1. First log into your AWS Console and click on “Server Migration” under the Migration section.
    aws server migration
  2. At the AWS Server Migration Service page click on Get started.
    aws server migration service get started
  3. Click on the Download OVA button and then deploy the downloaded OVA into your vSphere environment.
    aws sms download ova
    deploy aws sms connector
  4. Once the Server Migration Service Connector has been deployed, open a browser window and go to the IP address of the just deployed OVA. Then click on Get started now.
    load aws server migration service
  5. Agree to the license agreement then create a password, then click on Next.
    aws server migration service password
  6. Now you’ll be presented with information on how to log into the command line interface an configure network settings, such as a static IP. For this proof of concept I’ll just use a DHCP address. Click on Next.
    aws server migration service network info
  7. Check if you want to upload logs automatically as well as if you want the AWS Connector to stay updated on it’s own.
    aws server migration service log uploads upgrades
  8. Next select which region you want your VM’s to be migrated to and enter the AWS access and secret key from the account creation above.
    aws server migration service region
  9. Now just enter your vCenter host name and credentials.
    aws server migration service vcenter
  10. Once the AWS Server Migration Service appliance has been configured you’ll be taken to the status page that should look something like the below.
    aws server migration service complete
  11. Now go back to the AWS Console and click on “Server Migration” under the Migration section.
    aws server migration
  12. Then click on Connectors on the left menu and the click on Import server catalog. This might take a couple minutes as it creates a list of all the VM’s in your vCenter.
    aws sms connectors
  13. After the import is completed you’ll be taken to the Servers tab. Select the server(s) you’d like to replicate to AWS and then click on Create replication jobs.
    aws sms servers create replication jobs
  14. Next you’ll configure your license type: Auto, AWS, or BYOL.
    aws sms servers create replication jobs server settings
  15. Now configure your desired replication settings such as how often to replicate the server(s), when to start replication and enter your IAM service role.
    aws sms servers create replication jobs configure replication
  16. Review the settings and click on Create.
    aws sms servers create replication jobs review
  17. And finally, once the replication job completes you’ll be able to easily spin up the VM on AWS by simply going to the Replication Jobs tab on the left, select your desired server and then from Actions click on “Launch instance from latest AMI“.
    aws server migration service migrate launch latest amiOr you can also launch the VM on AWS through the EC2 dashboard and selecting the desired AMI and clicking on Launch.
    aws server migration service migrate launch ami

And with that you’ve now migrated virtual machine(s) from VMware over to AWS and done pretty painlessly as well.