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.

Screenshot_1

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

https://www.cisco.com/c/en/us/td/docs/security/ise/2-3/install_guide/b_ise_InstallationGuide23/b_ise_InstallationGuide23_chapter_011.html?bookSearch=true

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

https://www.vmware.com/support/developer/ovf/

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”].

Screenshot_2

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-2.3.0.298-virtual-SNS3415-600.ova” “C:\ISE-2.3.0.298-virtual-SNS3415-600.vmx”
  5. The above will convert from the OVA to the VMX in the same directory of C:
Screenshot_4

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

Screenshot_6

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-2.3.0.298-virtual-SNS3415-600.vmx C:\OVF\ISE-2.3.0.298-virtual-SNS3415-600.ovf

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.

Screenshot_3

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.

 

 

ADDING A NUTANIX NETWORK SHARE AS A DATASTORE IN VMWARE ESXI

ADDING A NUTANIX NETWORK SHARE AS A DATASTORE IN VMWARE ESXI

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: 192.169.9.25 – 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

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

 

de-hexa

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”.

 

Capture

 

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

migrate-virtual-machine-aws-01

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.

migrate-virtual-machine-aws-02

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-03-600x345.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-04-600x233.jpg

Select Users tab and click Add.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-05-600x248.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-06-600x348.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-07-600x394.jpg

Click Create user.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-08-600x391.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-09-600x278.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-10-600x323.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-11-600x580.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-12-600x312.jpg

Enter the Role name and a Description then click OK.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-13-600x258.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-14-600x444.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-15-600x356.jpg

Click Finish to save the configuration.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-16-600x356.jpg

Permissions assigned to the new role.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-17-600x399.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-18-600x566.jpg

Deploy the Server Migration Connector appliance

Access the AWS portal and login with your account.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-19-600x380.jpg

Select Server Migration Service under Migration.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-20-600x303.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-21-600x342.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-22-600x304.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-23.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-24-600x495.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-25-600x495.jpg

Select the compute resource then click Next.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-26-600x495.jpg

Click Next to continue.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-27-600x495.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-28-600x495.jpg

Specify the correct Destination Network to use then click Next.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-29-600x495.jpg

Click Finish to deploy the appliance.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-30-600x495.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-31-600x388.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-32-600x290.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-33-600x389.jpg

Accept the EULA and click Next.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-34-600x386.jpg

Enter a New password and click Next.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-35-600x386.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-37-600x373.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-38-600x388.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-39-600x274.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-40-600x440.jpg

Click Trust to validate the certificate.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-41.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-42-600x171.jpg

The SMS Connector dashboard.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-43-600x388.jpg

Import the server catalog

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-44-600x326.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-45-600x276.jpg

Click Import to proceed.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-46-600x216.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-47-600x393.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-48-600x413.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-49-600x413.jpg

Click Create to replicate the selected VM to AWS.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-50-600x413.jpg

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

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-51-600x413.jpg

Replication details can be displayed by selecting the active replica.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-52-600x417.jpg

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.

https://nolabnoparty.com/wp-content/uploads/2018/10/migrate-virtual-machine-aws-53-600x269.jpg

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.

Background

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 10.0.0.0/16 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 192.168.0.0/16.

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:

    LDAP://destination.local/OU=Users,OU=destination,DC=destination,DC=local

  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.

Error when uploading files to vCenter Server Appliance using WinSCP (2107727)

Post Source : VMWare KB 2107727
  • Attempting to upload a certificate file to the vCenter Server Appliance using WinSCP fails
  • You see the error:

    Host is not communicating for more than 15 seconds. If the problem repeats, try turning off 'Optimize connection buffer size'.

 Solution
When you copy files using WinSCP, part of the operation happens on the target Linux system. The default Appliance Shell cannot be the remote partner of WinSCP. You must enable the Bash shell on the appliance, as follows:
  1. Initiate an SSH connection to the vCenter Server Appliance.
  2. Provide the root user user name and password when prompted.
  3. Run this command to enable the Bash shell:

    shell.set --enable True

  4. Run this command to access the Bash shell:

    shell

  5. In the Bash shell, run this command to change the default shell to Bash:

    chsh -s /bin/bash root

  6. Use WinSCP to upload the certificate files to the vCenter Server Appliance.
  7. To return to the Appliance Shell, run this command:

    chsh -s /bin/appliancesh root

Alternatively, you can use PSCP to copy files from a Linux system to the vCenter Server Appliance. On Linux, the commands are run locally and the transfer succeeds.