IT HandOnLabs guide

This error shows that sysprep was run multiple times on the machine, please open a command prompt, type:slmgr /dlv to view how many times of remaining Windows Activation count. Generally speaking, to sysprep the image on a single computer for multiple times, you need to configure the Microsoft-Windows-Security-SPP |SkipRearm to 1 in the unattend.xml file. I am assuming whether you configure the Microsoft-Windows-Security-Licensing-SLC | SkipRearm to 1 instead of SPP, the SLC setting is deprecated and should not be used.

As a work around of this problem, please type: regedit in the Start Search box to open Registry Editor, set the value of GeneralizationState under HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus to 7, then run sysprep again.

If the same issue still persists, please unistall the MSDTC and Reinstall it, then try the sysprep.

DON’T REJOIN TO FIX: The trust relationship between this workstation and the primary domain failed

If you Google “the trust relationship between this workstation and the primary domain failed”, you get plenty of information from support blogs and Microsoft articles; however, most of them ask you to rejoin your machine to the domain. That’s not always possible.

TL;DR

You got this error and you can’t simply unjoin and rejoin because the machine is a Certificate Authority. Run this command from PowerShell:

Reset-ComputerMachinePassword [-Credential ] [-Server ]

What’s the problem and how did I get here?

The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined. The machine’s private secret is not set to the same value store in the domain controller. You can think of this secret as a password but really it’s some bits of cryptographic data called a Kerberos keytab stored in the local security authority. When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally. I think you can also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller. This solution also fixes that problem.

The standard fix

This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before. When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months. The password changes are required to maintain the security integrity of the domain.

Support blogs and Microsoft will generally tell you to rejoin the domain to restore the trust relationship. Another option they will give is to delete the computer object and recreate it without a password and rejoin.

I’m not a fan of any of these options. This seems heavy handed and sometimes they aren’t even possible.

Recently, when I ran into this problem, the virtual machine that reset was an enterprise certificate authority joined to my test domain. Well, guess what, Microsoft will not allow you to rename or unjoin a computer that is a certificate authority—the button in the computer property page is greyed out. There may be another way to unjoin but I wasn’t going to waste time on it when it isn’t even necessary.

UPDATE: An even better fix (IMO)

Just change your computer password using the Reset-ComputerMachinePassword cmdlet from Powershell v3!

I haven’t looked at this problem for a while, but it seems to come up very often and there has been a lot of positive response. I wanted to point out an improvement (a more up-to-date method) that came from Lord_Arokh. Powershell v3 shipped with a cmdlet for resetting computer passwords. For those with Powershell skills, this is a much better option. Powershell v3 ships with the latest version of Windows and can be downloaded from Microsoft:

I noticed that on my Windows 8 install, I only received partial help when I issued the Get-Help Reset-ComputerMachinePassword command. You can fix this by opening Powershell with administrative rights and running Update-Help.

You can use the Get-Credential cmdlet for a secure way to generate a PSCredential, which can be stored in a variable and used in a script. You will want to generate a credential for an Active Directory user with sufficient rights to change the computer’s password. The Server parameter is the domain controller to use when setting the machine account password.

You need to be able to get onto the machine. I normally just log in with the local Administrator account by typing, “.\Administrator” in the logon window. I hope you remember the password. If you’re creative and resourceful you can hack your way in without the password. Another option is to unplug the machine from the network and log in with domain user. You will be able to do disconnected authentication, but in the case of a reset machine, remember that you may have to use an old password. Your domain user’s cached credential has the same problem as the machine’s private secret.

You need to make sure you have netdom.exe. Where you get netdom.exe depends on what version of Windows you’re running. Windows Server 2008 and Windows Server 2008 R2 ship with netdom.exe you just have to enable the Active Directory Domain Services role. On Windows Vista and Windows 7 you can get it from the Remote Server Administration Tools (RSAT). Google can help you get them. For other platforms see this link: http://technet.microsoft.com/en-us/library/ee649281(WS.10).aspx

Extra steps if the machine is a domain controller. If the broken machine is a domain controller it is a little bit more complicated, but still possible to fix the problem. I haven’t done this for a while, but I think this works:

Turn off the Kerberos Key Distribution Center service. You can do this in the Services MMC snap-in. Set the startup type to Manual. Reboot.

I hope this is helpful. This problem comes up every few months for me, so I wanted to document it for my own use. It is difficult to find when you just search for the error you get in the login window.

At this point, we are ready to start the upgrade process from 5.1 to 5.5. It should be noted that this is not an “upgrade” but actually an install and reconfigure. What I mean is that we are actually deploying a new appliance, and the upgrade process automates moving the database, and settings over to the new appliance – including networking settings. So, in the end, our new 5.5 vCSA will be powered on with all our data, and the old 5.1 vCSA will be powered off, ready to be deleted.

The Upgrade:

First, we will deploy the OVA file. I won’t go over deploying the OVF template, since it’s a fairly easy process.

The 5.1 server will generate a key – paste that key into the new 5.5 vCSA

Click Next, and choose to generate new SSL Certificates (unless you are using custom certificates)

Choose Next, and type in a new (or the same) SSO admin password

On the next screen, we choose what hosts will be managed by the new appliance. Select all the hosts to start the upgrade checker.

The following screen will report on any host problems that may be preventing an upgrade.

At this point, we are ready to start the upgrade. Make sure to take a SNAPSHOT of the current vCSA 5.1 server. If for some reason the upgrade does not complete, both vCSA appliances will be in an unusable state. Reverting back to the snapshot will be the recovery method should that happen.

Check the box to confirm that you have taken a snapshot, and click start.

The server proceeds with the upgrade, and gives no additional feedback until complete.

To monitor the progress, SSH into the 5.1 vCSA server, and type:

tail -f /var/log/vmware/vami/upgrade.log

Once completed, the wizard will display the successful message.

The 5.1 vCSA appliance will shutdown, and the new 5.5 vCSA will reboot, and be configured with the same IP address, and all data. It may take a longer time for all the services to start for the first time on the new appliance.

After upgrading your ESXi hosts to 5.5 the “Upgrade Virtual Hardware” function of the legacy vSphere Client will update the virtual hardware of a VM to version 10, although the legacy client is not able to edit the properties of version 10 VMs (see my earlier post about How to update to ESXi 5.5 …). Only the Web Client is able to do this with version 10 VMs, and that requires vCenter. If you do not have vCenter available or do not feel comfortable with the Web Client for other reasons then you want to avoid upgrading virtual hardware to version 10. But how can you upgrade to only version 9?Depending on the type of license you have and the availability of vCenter there are several ways to achieve this:1. If you are using paid or non-expired evaluation licenses, have vCenter available with the Web Client installed and configured then you can use the Web Client to schedule a virtual hardware upgrade for a VM in its Virtual Hardware settings:

Choose Compatible with “ESX 5.1 and later” to upgrade the VM’s virtual hardware to version 9 upon next reboot.2. If you are using paid or non-expired evaluation licenses for your ESXi host(s), but do not have vCenter available then you can use a simple PowerCLI cmdlet:

1# Connect to host

2Connect-VIServeryour_hostname

3# Upgrade hardware of the VM named Hw8Test

4Set-VM-VMHw8Test -Versionv9 -Confirm:$false

The VM needs to be powered off before you run this command.3. If you are using the free ESXi license then you cannot use the PowerCLI script, because the free license limits write access through the APIs. But you can use the following vim-cmdcommands in an ESXi shell: vim-cmd vmsvc/getallvmswill list all VMs that are registered on the host. Find the VM that you want to upgrade and note itsvmid. Then run vim-cmd vmsvc/upgrade vmid vmx-09

Guide for upgrading VMware ESXi (5.1 to 5.5U2)

Introduction

While i continiously have to deal with ESXi hypervisors in my Sysadmin job, i also have to take care of that they’re up to date. And because it’s a recurring task, updating an ESXi is quite easy as long as you pay attention to certain things.

This guide is about those nitty gritty details and how to update the ESXi Hypervisor only by using vSphere Client and the esxcli.

Start with the prerequisites

At first we should get the details about which version of ESXi we have running as well as its Image-Profile version. Turn on the vSphere Client and connect to your ESXi. Now select your ESXi in the left folder list and you can see your actual version on the blueish bar on the right which tell something like this:

esxi.example.com VMware ESXi, 5.1.0, 123456

In the General tab below you can find the Image Profile version as well. We will now update both of them.

To make sure you can update directly to the new version you want to have, check out the following Link for a update matrix. For us the update path from 5.1 directly to 5.5 Update 2 is possible.

Updating

ESXi Main Version

At first, make sure that SSH is enabled and allowed in the ESXi firewall. Now get the offline bundle package for the desired version, for exmaple:

update-from-esxi5.5-5.5_update02-2068190.zip

You can get those updates in your personal VMware portal!

Upload this to your hypervisors datastore via SCP or the vSphere clients built-in datastore manager and login to your esx command line afterwards:

ssh username@esxi.example.com

Now migrate all your virtual machines to another hypervisor or shut them down. After you’ve done this put your esxi into maintenance mode to prevent automatic restarts of your VM’s:

esxcli system maintenanceMode set –enable on

The next step is testing and if everything is fine there, finally installing it:

After a reboot you should see the new Image-Profile. If not run the next command to remove all old Image-Profile traces while installing the new one (you can safely run the following command multiple times):

Another reboot later, your main and Image-Profile versions should be up to date.

Finalizing the Update

You’re almost done!

The last thing you need to do is disabling the maintenance mode just by right-clicking the hypervisor in the folder list in the vSphere Client and select “Disable Maintenance mode”. Now restart or migrate your virtual machines and you’re done until the next update.