Configuring VMware ESXi 5

You installed your ESXi host, but some configurations needs to be done before using it in production like IP, host name etc. You could just us it as it is but I don't recommend for example to assign an IP address from a DHCP server even if you create a reservation for it. What if that DHCP server crashes ? Well…I'll leave this to you to think what can happen.

To start configuring the ESXi host press F2 from the keyboard then provide the log on credentials. These credentials were set during the installation.

The first section, Configure Password is there if you want to change the root password, the one that you just typed to log in. Press ENTER to change it and in the first field Old Password provide the current password, then type the new password in the New Password and Confirm Password fields. Hit ENTER when you're done.

     

If you don't provide a complex password you will get the error message "The password change operation failed. Please ensure that your password meets the complexity criteria set by your administrator."

Configure Lockdown Mode forces all operations to be performed through vCenter Server allowing only the vpxuser access to authenticate on the host. No other user can perform operations on the host remotely. This option is grayed out until the ESXi host is added to a vCenter server, but once is part of a vCenter Infrastructure you can configure it.

The Configure Management Network section is where you can configure the network and provide a name for the host. Press ENTER to configure this section.

Network Adapters – by pressing ENTER then the space key you can disconnect and connect the network.

VLAN (optional) - if you need to tag the traffic; only if your organization is using VLANs. For small business usually it's not the choice.

IP Configuration –  here you can configure the ESXi host network with a static IP address or let it use a DHCP server. Most of the times you will configure it with a static IP address. When you're done with the configuration press ENTER to save the changes.

IPv6 Configuration – the same as the one above only that is for IPv6 addresses.

DNS Configuration – let you set the DNS server the ESXi host will use for name resolution. One other thing to configure is the host FQDN. Once you configure the FQDN you should add an entry for this on your DNS servers.

Custom DNS suffixes – only if have multiples domains and want this ESXi host to resolve the host names from those other domains without typing the FQDN. Not used so often, but who knows…

If you made changes, when you want to exit the Configure Management Network menu you will be asked to either apply the changes or drop them.

Restart Management Network section simply restarts the network services on the host.

Test Management Network will do a quick test by pinging the configured gateway and DNS servers.

Restore Network Settings will simply restore all the network configurations to their defaults. Your adapters will be configured to use a DHCP server. Be careful because all the VMs on the host will be stopped if you go forward with this. The rest of the menu sections are self-explanatory, so I'll leave them to you to check them out. When you return to the initial screen the network information it's changed based on your configuration.

Deploying and Configuring an Read-Only Domain Controller (RODC)

I know most of you have to maintain branch offices, and they are not easy and especially not secure. Domain controllers in those locations can be easily stolen or compromise, leaving your users and your network vulnerable to attacks. Microsoft thought about this, and starting with Windows Server 2008 they implemented a feature in the server product so domain controllers can be in read-only mode. So even if is stolen or compromised that domain controller has no passwords or AD accounts on it. You can configure it to cache credentials and passwords, but by default is not going to. In order for a RODC to exist you still need to have writable domain controller but this is on a main site where security can be guaranteed and specialized personal exist. More information about RODC can be found here. The AD infrastructure needs to meet some prerequisites before a RODC can exist:

- The forest functional level should be at least at Windows Server 2003.

- A writable domain controller running Windows Server 2008 or Windows Server 2008 R2 that is also a DNS server need to exist in the same domain as the RODC.

- If your environment is Windows server 2003, you need to prepare the forest and the domain. Just follow the first section of that article and you will be good-to-go.

- The PDC emulator should be running on Windows server 2008.

For this guide there is a single forest and a single domain. The branch office is connected to the main site trough a VPN connection and has a RODC running Windows server 2012. The installation of a RODC is just like adding and additional domain controller to your network. What makes the difference is the Domain Controller Options page, where you need to check the Read only domain controller (RODC) box.

As soon as you check that box you will get additional options on the left of the wizard. On the section where it says Accounts that are allowed to replicate passwords on the RODC, there is a security group already created. Users and computers that are part of this security group will have their passwords replicated/cached on the RODC. You can create and add your own groups, but I'll show you how is done from the RODC properties page, later on. As you can see in the section Accounts that are denied from replicating password to the RODC, are accounts with administrative access that are denied from replicating passwords on the RODC. In case the server is compromised, the attacker can't find or decrypt the admin account password since it does not exist on the server. Is nested only on a writable domain controller on the main site. By having a small environment here, the Allowed RODC Password Replication Group will do the job just fine. Later I will add some users and computers accounts to this group, to see how replication/catching works. Continue the wizard using the defaults or following the above mentions article.

After the server is promoted to a domain controller, you can open Active Directory Users and Computers (ADUC) on the RODC. If you try to create a new user, you are allowed. And now you might think, why since this is a read-only server. Well…take a look at the top of the console, you can see that you are connected to the PDC, which is the writable domain controller on the main site. Right-click the server name (the PDC) and choose Change Domain Controller.

From the list select the RODC then click OK. As soon as you click the button, a message pops-up telling you that no rights operations can be performed on the domain controller.

     

Try now to create a user account. The option to create it is not even in the menu, and I'm logged in with an Enterprise admin account. Next, I tried to delegate the control of an OU and delete a user account, reset its password. Trying to do so, I either get a warning message or the options were grayed out.

   

Right now, I know this doesn't help you understand the RODC idea, but the next section may fill the void. I'm going to simulate an offline WAN connection, so the RODC can't communicate any more with a writable domain controller on the main site. On one of the clients from the branch office I will log on, or at least I'll try to log on using an AD account. After almost two minutes waiting to log on, I finally got a message: The trust relationship between this domain and the primary domain controller has failed. This happened because the workstation can't find a writable domain controller to verify the user credentials, and the RODC does not have the credentials cached for this user account.

     

You can also see this if you open ADUC on a writable domain controller, go to the Domain Controllers container, right-click the RODC and choose Properties.

Click the Password Replication Policy tab then hit the Advanced button. As you can see my User01 account is not listed here. You can click the Prepopulate Passwords button to cache the user credentials manually, and you should do this only if you are in hurry or something. A writable domain controller needs to be available for this.

     

Another way to cache users credentials is to add those users and computers accounts to the Allow RODC Password Replication Group security group. Here I have two users that I want their credentials to be cached so in case the WAN connection goes down, they will be able to log in. These are those king of users that know some stuff about computers, so I want them to be able to troubleshoot small problems when needed. Make sure you also add their computer accounts or is not going to work.

This credentials won't be cached right away, but after a few minutes, logins and restarts, they will eventually appear in the Advanced Password Replication Policy window.

If I take the WAN connection offline again, these two branch office users will be able to log in to computers that are cached on the RODC.

Now, if you want to change the default security group from the Password Replication Policy all you have to do is open the RODC properties. Here, go to the Password Replication Policy tab, hit the Add button and add the security group you created in AD. This must be done on a writable domain controller. Once you click the Add button, choose the settings for the account, if you want to deny or allow replication.

Type the security group(s) you want to add to the policy.

All you have to do in order for the replication to work, is add users and computer accounts to this/those group(s).

Creating a Hyper-V Server 2012 Cluster

If you want to virtualize your network, and if you want to use Hyper-V for that, I recommend you go with server 2012. Hyper-V version 3 works great and has PowerShell support without you buying SCVMM. Now that your environment is growing, soon you will need highly available VM's and you can do that by creating a Hyper-V Cluster. Then if a Hyper-V host goes down, your VM's will be migrated to another available host in the cluster. Well yeahh, those VM's will be powered off, but as soon as they are migrated, they will be automatically powered back on. This means that users can resume their work in a few minutes, instead of hours or even days in some cases. Before you have a Hyper-V cluster, first you need to create a Windows Failover Cluster. After you're done with that, you can go ahead and install the Hyper-V role on those clustered servers, as we are going to do in just a sec.

For this guide I have three Windows server 2012 Core servers already in a Windows cluster. I presume you have your Windows Failover Cluster created so let's move on.

Since this is a test environment I will use the domain controller as a central station, to install and manage the environment remotely, being possible with server 2012.

Right now if you right-click the cluster name and try to create a VM you can't since the Hyper-V role is not installed. To install the role open Server Manager, right-click one of the servers that are part of the cluster and choose Add Roles and Features.

From here on just follow the wizard using the default options, and when you get to the Select server roles page check the Hyper-V box then click Add Features.

     

On the Create Virtual Switches page select the network adapter you want bind to the virtual switch. Without a virtual switch VM's will not be able to communicate with other machines in the network. Most of the times this is the adapter that is part of the LAN, and users can access it. If you don't want to make a choice now, you can skip it and do it later from the Hyper-V Manager console.

Here if you want to use live migrations, you have to check the box Allow this server to send and receive live migrations of virtual machines. Since I'm not going to do live migrations in this lab, I'll just continue the wizard.

I don't recommend you leave your VM's to run on the C drive. Since we are in a cluster environment provide the drive letter for your cluster disk, the one that all cluster nodes can access. Maybe you are using CSVs (Cluster Shared Volumes); in that case provide the path to the CSV.

On the Confirmation screen just click the Install button to begin the installation. Don't forget to check the box Restart the destination server automatically if required, because Hyper-V will definitely require a few restarts. Don't panic if the wizard is not finished even after 5 minutes of running, because is waiting for the server reboots; and you know the server will reboot a couple of time until the Hyper-V role is successfully installed. Repeat this step for the rest of the servers that are part of the cluster.

     

Now that all nodes in the cluster have the Hyper-V role installed, we can now create high available VM's. Just right-click Roles in Failover Cluster Manager and choose Virtual Machines > New Virtual Machine. You can also use the Hyper-V Manager console.

Select the node in the cluster where you want to place this VM.

From here on is just the usual New Virtual Machine Wizard. Right after you past the Before you begin screen you get to the Specify name and location one. Here you have to be careful where you place the VM, because the default path is on the C drive. This happens only when you are using the Failover Cluster Manager console to create VM's. Continue the wizard and create the VM.

     

To test this, leave the VM running and power off the cluster node where is running. In my case is running on HV-Node1.

As soon as I power off the Hyper-V host (HV-Node1) the VM is migrated to another node in the cluster and automatically started. The only downtime clients have is until the OS is booting. There is a downside of this. If a user has a document opened on a VM and is not saved when the Hyper-V host fails, the user will lose that unsaved data.

     

Looks like it works, and it works pretty damn good. Another benefit of this, is that you don't have to pay for those enterprise virtualization software to have high available VM's.

Install integration services when the virtual machine is not running

A lot of people about deploying integration services (integration components) lately.  As it turns out, they're pretty easy to patch offline with existing Hyper-V tools.

First, why would you update integration services on a not-running (offline) VM?

Offline VM servicing is valuable for VM templates places that create new VMs frequently since it allows you to keep VM templates up-to-date.  While this post targets exclusively integration service updates, the same update approach applies to many updates as well as any configurations specific to the environment.  Keeping the VM images fully up to date and configured before they are deployed saves significant setup time and support every time a new VM is created.

Here is a detailed write-up about deploying and updating integration services on an offline VM – both VHD/VHDX – using out of box PowerShell tools and a cab (cabinet) file that comes bundled with Server 2008 or later Hyper-V hosts.

Before you start, open a PowerShell console as administrator.  Make sure Hyper-V is installed and you're working from the management (host) OS. The management OS must be Server 2008R2 or newer and more recent than the VM OS you're patching.  I tested this script with a Server 2012 host.

For default Hyper-V installs, the CAB containing the up-to-date integration components will be located in [HostDrive]:\windows\vmguest\support.  From there, choose your architecture; for my machine, I choose amd64.  X86 people, you're files are there too.  This file contains all of the components built into the VM Guest ISO.  To update integration components offline, we're only interested in the two cab files highlighted below.

There will be two files:

• Windows6.x-HyperVIntegrationServices-x64.cab corresponds with Windows 7 and earlier guests. Tested: Server 2008 R2, Windows 7 (enterprise and enterprise sp1).
• Windows6.2-HyperVIntegrationServices-x64.cab corresponds with windows 8 and Server 2012 guests. Tested: Server 2012, Windows 8.

Note: this process only works for Windows 2008R2 / Windows 7 and later operating systems. It works with both vhd and vhdx files.

You will need the path to this file.  From here on out I'll refer to it as $integrationServicesCabPath.  If you pick the wrong one it will fail a version check without harming the guest.

$integrationServicesCabPath="C:\Windows\vmguest\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab"

The next step is to apply the cab to the offline VM.

First, you'll need the path to your VM image, I'm going to refer to this as $virtualHardDiskToUpdate.

$virtualHardDiskToUpdate="D:\client_professional_en-us_vl.vhd"

Next, mount the image as a pass-through disk (unprotected data and direct I/O) and keep track of the disk number returned.

$diskNo=(Mount-VHD -Path $ virtualHardDiskToUpdate –Passthru).DiskNumber

Check to make sure the operational status is online and find the drive letter so we know which drive to patch.

(Get-Disk $diskNo).OperationalStatus

$driveLetter=(Get-Disk $diskNo | Get-Partition | Get-Volume).DriveLetter

In my case this returned "online" and "E" (stored in $driveLetter).  If you mounted a VM with Windows fully installed, the chances are good it'll mount more than one drive depending on the VMs particular setup.  If this is the case, find the drive with all of the Windows OS files – apply the integration service update to that one.  If the status returns not online prepare the image by running:

Set-Disk $diskNo -IsOffline:$false -IsReadOnly:$false

Now the mounted VHD is ready to be patched.

Add-WindowsPackage -PackagePath $integrationServicesCabPath -Path ($driveLetter+":\")

You should see a blue progress bar at the top of PowerShell.  Enjoy watching the little yellow o's fill your screen.  If the cab couldn't apply, make sure you're using the right version for your guest OS and the right drive.  If the VM is running, it will not patch.

Finally, dismount the VHD.  Notice you dismount using the image path and not the mounted drive letter.

Dismount-VHD -Path $virtualHardDiskToUpdate

Here's a more reasonable, consolidated, PowerShell Script:

$virtualHardDiskToUpdate="D:\client_professional_en-us_vl.vhd"
$integrationServicesCabPath="C:\Windows\vmguest\support\amd64\Windows6.2-HyperVIntegrationServices-x64.cab"

#Mount the VHD
$diskNo=(Mount-VHD -Path $virtualHardDiskToUpdate –Passthru).DiskNumber

#Get the driver letter associated with the mounted VHD, note this assumes it only has one partition if there are more use the one with OS bits
$driveLetter=(Get-Disk $diskNo | Get-Partition).DriveLetter

#Check to see if the disk is online if it is not online it
if ((Get-Disk $diskNo).OperationalStatus -ne 'Online')
{Set-Disk $MountedVHD.Number -IsOffline:$false -IsReadOnly:$false}

#Install the patch
Add-WindowsPackage-PackagePath $integrationServicesCabPath -Path ($driveLetter + ":\")

#Dismount the VHD
Dismount-VHD-Path $virtualHardDiskToUpdate