Monday, June 29, 2015

VMware Tools upgrade error, Unable to uninstall previous version

Last week when I was upgrading VMware tools on some virtual machines, on one virtual machine tools update got failed as VMware Tools tried to uninstall the previous version but it failed because it couldn't reference the previous VMware Tools msi

This is an issue with Microsoft Windows Installer and does not affect all Windows 2008/2003 systems. The problem can occur when the original install path from the older version of VMware Tools is invalid, such as if the install path was E:\ and that path is no longer present.

To resolve this issue, one must perform a forced uninstall and reinstall of VMware Tools.

To uninstall and reinstall VMware Tools:
  1. Right-click the virtual machine and click Guest => Install/Upgrade VMware Tools.
  2. Open a Console to the virtual machine and log into the guest operating system.
  3. Click Start > Run, type cmd, and click OK.
  4. Change the drive to your CD-ROM drive (For example, D:\), type setup /c and press Enter to force removal of all registry entries and delete the old version of VMware Tools.
or 

Note: For 64-bit guest operating systems, type setup64 /c instead.

The above procedure will hardly take few seconds and once completed, Open My Computer, browse CD-ROM and install VMware tools using the GUI interface (This must be done from the GUI). 
When the installation completes, reboot the guest operating system.

Reference: VMware KB# 1012693. Aslo have a look at KBs # 10013542007298 for related error and fixes.

That's It... :)


Sunday, June 28, 2015

How to add another NIC card to nested esxi host... ;)

Some people might find this post funny but the fact is I was in the impression like to add another network card to my nested esxi hosts I will have to connect another physical NIC to my Lab machine. Earlier I had edited esxi VM setting and added another NIC card to esxi VM but was unable find it when checking via vSphere client so i thought, to add another NIC I will have to connect another NIC to my Lab machine first.

Today I was looking for a supported cheap NIC card online but couldn't find one so approached one of my vExpert blogger friend Anjani Yadav for suggestion and when he said you don't need a second physical NIC card in order add another NIC to your nested lab hosts, simply edit the esxi VMs and add another NICs for VM settings, I sad already did with no luck the second thing he said....after adding the new NIC did you enable it from DCUI....then my impression was opsssssssss I missed this step ;)

Anyways here are the steps to add one or more network cards to your nested Lab Esxi hosts.....
  • First edit the esxi vm and add one or more NICs,
  • Now login to Esxi DCUI and Select Configure Management Network => Network Adaptors

here you will find your just added NIC cards, what you do here is, just enable them

and click Enter to save.

Then Esc, Y.

Now using vSphere client login to you vC or directly to esxi host => Configuration, select Network Adapters and you will find your newly added Network Card available here.


As you are seeing here, its in standby,


Go to Properties, NIC teaming


Select the standby NIC and click Move up....


Update: As pointed out by Roshan Jha sir, alternatively we can do the same form vC itself.

To do so, Select the esxi host where you have already added the Network Card => Configuration=> Networking => Go to Properties of vSwitch


Now select Network Adapters and click Add,


On next screen you will find newly added NICs,


Select the newly added Network Cards from here and click Next........then one or more other clicks and you are done :)

Finally I can brush up myself on vDS that I couldn't do earlier due to my wrong assumption of physical Network Card... :P

Thats it..... :)


Thursday, June 25, 2015

VMware Workstation Tweaks

Toady when i was looking for a way to disable swap file creation on VMware Workstation VMs, came across a very interesting blog post related to VMware Workstation tweaks, VMWARE PERFORMANCE ENHANCING TWEAKS. This could be very useful at times so thought of making a note of it.

Tweak: Disable memory swap files .vmem files
In the VMware settings.ini file add the following line
mainMem.useNamedFile = "FALSE"
Settings.ini file is located file either at C:\ProgramData\VMware\VMware Workstation\
On Windows7:
or C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\folders, depending on your operating system. 
For VMware Player: ## mainMem.useNamedFile = “FALSE” ## needs to be in the .vmx-file
For VMware Fusion on Mac and Linux instead of mainMem.useNamedFile you have to set mainMem.backing flag.
VMware Fusion Config files are located at:/Users/username/Library/Preferences/VMware Fusion/preferences and/Users/username/Library/Preferences/VMware Fusion/config
mainMem.backing = "swap"
Tweak: Disable log files for VM
Open your .vmx file in a text editor and add the following line:
logging = "FALSE"
Alternatively you can specify a different location to store the log file, if you ever need them:
log.filename = "c:\Windows\Temp\vm1.log"
Tweak: Disable Unity Mode
Unity might be a great feature for running virtual desktops  operating systems, but it is not the most useful for virtualizing server OS. An annoying sign of enabled unity is GuestAppsCache or caches folder with a large number of files in its appData-subfolder. In order to disable it for your VM, open your .vmx file in a text editor and add the following line:
isolation.tools.unity.disable="TRUE"
unity.allowCompositingInGuest="FALSE"
unity.enableLaunchMenu = "FALSE"
unity.showBadges = "FALSE"
unity.showBorders = "FALSE"
unity.wasCapable = "FALSE"
Tweak: Disk & Memory I/O Performance Optimization
Disable memory trimming:
MemTrimRate = "0"
Tweak: Disable page sharing:
sched.mem.pshare.enable = "FALSE"
Disable snapshots if you are not using them and prefer full backups,
snapshot.disabled = "TRUE"
Disable scale down of memory allocation:
MemAllowAutoScaleDown = "FALSE"

That's it.... :) 


Monday, June 22, 2015

How to ping multiple hosts and save result in a test file

First, put all of your server names into a text file with each server name on a separate line. Let's call it "servers.txt" and save it (as you going to ping server names so make sure name resolution is happening).

Next, open Command Prompt and navigate to the folder where you just created the file in which you listed the name of servers.

Now, enter the following line on the command prompt:
for /f "tokens=1" %a in (servers.txt) DO @ping -n 1 %a
This will attempt to ping every system in the list and return the result. 
If you want to save the ping results, use this,

for /f "tokens=1" %a in (servers.txt) DO @ping -n 1 %a >> PingResults.txt 
The above script only sends one ICMP packet to each server you list. Now, that’s probably good for just seeing if the server is accessible or not. You may want to increase the number of ICMP packets sent to each server. You can do that by changing the value after -n.

You can also modify the ping command at the end of the command above as needed with options pertaining to ping.

or Using PowerShell
Test-Connection server1, server2, etc, | Out-File C:\PingResults.csv

 Or do it this way to get the list of servers

 $Computers = Get-Content C:\Computerlist.txt
Test-Connection $Computers | Out-File C:\PingResults.csv

That's it.......... :)



Sunday, June 21, 2015

The Trust Relationship between this workstation and the primary domain failed...here is the fix

Today after reverting a Virtual Machine to a previously taken snapshot when I tried to login on this VM, end up with this domain/workstation trust relation error

Usually it can happen after restore operations, you restored a snapshot or restored a VM from old backup and the Windows VM can’t authenticate with the domain because the Trust Relationship between workstation and domain fails.
The reason why this problem happens is because of a "password mismatch." Passwords are typically thought of as something that is assigned to a user account. However, in Active Directory environments each computer account also has an internal password. If the copy of the computer account password that is stored within the server gets out of sync with the password copy that is stored on the domain controller then the trust relationship will be broken as a result.

The default domain value is 30 days, after that each workstation do a reset of their computer account password in AD

You can simply fix this issue by removing and then re-joining this system to domain.

But here is a better way where you don't need to domain re-join/reboot your system, 

Login to your DC and simply reset the affected computer's computer account.

or

login to affected system using local admin account and run this command:

netdom resetpwd /Server:DomainName /UserD:Administrator /PasswordD:AdministratorPWD

This will fix the Domain/Workstation trust relationship issue.

To prevent future occurrence of this issue in you Lab environment you can disable the group policy responsible for this setting "Disable machine account password change"
located here,
\Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options


or increase number of days by modifying the GPO Maximum machine account password age. 

Ref: Vladan Seget and Brien Posey's blog. 

That's it........... :)



Sunday, June 7, 2015

How to fix the issue of duplicate SID

You might have faced the issue of duplicate SID in your VMware or physical environment where you are using cloning/deploy from template/Image as a method to provision new systems.

Using Sysprep you can fix the issue of duplicate SID (NewSID wont work with 2008R2), follow these steps to generate a new SID:
  • Open Sysprep from Run => Sysprep or  by going to, "C:\Windows\System32\sysprep" and execute Sysprep by double clicking on Sysprep.exe

  • Ensure ‘System Out-of-Box Experience (OOBE)’ is selected and Tick the ‘Generalize’ option (this resets the SID) and Select ‘Reboot’ from the Shutdown Options.


Once you will click ok, it will take some time for sysprep to finish and then system will reboot.
 
(You can do the same in one go using this command "C:\Windows\System32\sysprep\sysprep /oobe /generalize /reboot")

After reboot you will have to enter some data, for example, Country or region, Time and currency and Keyboard input and you are done.

To ensure not to face duplicate SID issue prepare the OS using Sysprep before converting it to Template, Clone or Image.

Prior to taking your clone/image or converting to Template, just remember to use Sysprep as follows,
  • Run Sysprep, C:\Windows\System32\Sysprep\Sysprep.exe
  • Ensure ‘System Out-of-Box Experience (OOBE)’ is selected  and Tick the ‘Generalize’ option and Select ‘Shutdown’ from the Shutdown Options. 

(You can do the same in one go using this command "C:\Windows\System32\sysprep\sysprep /oobe /generalize /shutdown")
Once the machine has shutdown, convert it to Template/Image or Clone and you are good to go!

Note: One can check the SID of a system using PsGetSid. To use PsGetSid first you have to download it, then extract it from the archive PsTools (for example on your desktop) and from Command Prompt navigate to that folder,
C:\Desktop\PsTools\psgetsid COMPUTERNAME, where computername is the name of your computer.

That's it... however take a look at KB article 1005593 too for the issue of: When a virtual machine is deployed from a template and despite the fact that you chose the option to generate a new SID during template deployment and guest operating system customization the SID is always the same.........

Reset WSUS Authorization and get new WSUS SID ............2


Monday, June 1, 2015

vSphere Web client 5.1: For newer versions, the vCenter Server system must be registered with the Lookup Service

When using the “Simple Install” to install a new vCenter setup, you might encounter the following error when trying to register the vCenter server to the Web interface:
The vSphere Web Client Administration Tool only supports registration of vCenter Server version 5.0. For newer versions, the vCenter Server system must be registered with the Lookup Service to allow the vSphere Web Client to discover the system.
To resolve this, follow these steps:
  • Log in to the vSphere Web client as the admin account (admin@System-Domain) you created during the SSO installation
  • Browse to “Administration -> SSO Users and Groups”
  • Browse to the “Groups” tab and click on “__Administrators__”, Now click “Add Princilpals”
  • Select our vCenter server as the identity source and add the user “Administrator” to the list

Now login as “Administrator” in to the vSphere Web client, you should see the vCenter server listed in the objects. No further registration needed.

Note: These troubleshooting steps were originally posted at Lostdomain.org and as this was second time when I stuck with the same error so i thought of making a note of it.