How to use Hosts file

Path: C$\Window\system32\drivers\etc\
hosts
Imhosts.sam
networks
protocol
services

NOTE: Hosts is the name of the hosts file and not another directory name. It does not have an extension (extensions are the .exe, .txt, .doc, etc. endings to filenames) and so appears to be another directory in the example above.

CAUTION: If you find that you already have a "Hosts" file on your computer, I recommend that you back it up into another directory on your hard drive so that you may restore it if you do not like the results of the ad-blocking, or in case something else goes wrong while you are trying to set this up. It is always better to be safe than sorry in the event of an unforeseen mishap. Please make a backup copy.

"Hosts": Make sure you use the quotes to keep the file from being saved with an extension (like .txt). If you find the file has an extension, you will need to get rid of the extension by renaming the file in Explorer to simply "Hosts".

With a proxy server:

You should only need to do this step if you use a proxy server. Examples of proxy servers include: WebWasher, CookieCop Plus, and a web cache server provided by your ISP. If your hosts file does not seem to be working for you and you skipped this step, try coming back and completing this process.

In IE - choose tools:internet options:connections and choose your connection. If you are using a proxy server, make sure the box called "bypass proxy server for local addresses" is checked.

In Netscape - go to Edit: Preferences: Advanced: Proxies and click the manual setting. Then click on view and type "127.0.0.1" into the exceptions box at the bottom.

To disable Hosts from a DOS window:

cd windows (press enter)                                 rename hosts hosts.txt (press enter) 

To Enable Hosts from a DOS window:

cd windows (press enter)                                 rename hosts.txt hosts (press enter)

You can also use this to rename your Hosts file if it accidently has an extension on it.

*Do not do this if you use a proxy server, or the proxy will not work. In that case, you would have to delete all entries from your "Hosts" file except for the proxy entries to get the equivalent of disabling the Hosts file. To restore the ad-blocking Hosts file, you would then have to paste all the deleted entries back inside "Hosts".

Use browser to test changes

You may test your configuration by trying to visit a site that is listed in the Hosts file. Type in a site such as "www.alladvantage.com" and if your browser can not access it then you are in business! If you have problems, try closing your browser and reopening it, or try emptying your browser's cache before trying again. Also, you may need to reboot in some cases.

Another testing method is to see whether or not ads are being blocked on most of the sites you visit. Of course, not every ad will be blocked because of the restrictions listed above. You will be able to tell this by the fact that you will see empty boxes in the spots you used to see ads. If you would like to see some kind of picture there instead of the empty box while still blocking ads

Editing a "Hosts" file 

--------------------------------------------------------------------------------------------

# Copyright (c) 1993-1999 Microsoft Corp.

#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
192.168.xxx.xxx servername
192.168.xxx.xxx servername.domain.local
-----------------------------------------------------------------------------

VMware_Cannot create a snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine

• Creating a quiesced snapshot fails.
• While taking a snapshot, you see the error:
  
  Cannot create a quiesced snapshot because the snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine
   
• You may also experience this issue when you are doing a hot clone of a virtual machine. You see the error: 
  An error occurred while quiescing the virtual machine. See the virtual machine's event log for details 'VssSyncStart' operation failed: IDispatch error #8449 (0x80042301)
  
• The /var/log/vmware/vpx/vpxa logs contain entries similar to:
  2010-10-10T22:53:31.077Z [45EEEB90 info 'Default' opID=D1D8F924-00002337-83] [VpxLRO] -- ERROR task-768 -- -- vpxapi.VpxaService.createSnapshot: vim.fault.ApplicationQuiesceFault:
  --> Result:
  (vim.fault.ApplicationQuiesceFault) {
     dynamicType = <unset>,
     faultCause = (vmodl.MethodFault) null,
     faultMessage = (vmodl.LocalizableMessage) [
        (vmodl.LocalizableMessage) {
           dynamicType = <unset>,
           key = "msg.snapshot.quiesce.vmerr",
           arg = (vmodl.KeyAnyValue) [
              (vmodl.KeyAnyValue) {
                 dynamicType = <unset>,
                 key = "1",
                 value = "5",
              },
              (vmodl.KeyAnyValue) {
                 dynamicType = <unset>,
                 key = "2",
                 value = "'VssSyncStart' operation failed: IDispatch error #8449 (0x80042301)",
              }
           ],
           message = "The Guest OS has reported an error during quiescing.
  --> The error code was: 5
  --> The error message was: 'VssSyncStart' operation failed: IDispatch error #8449 (0x80042301)
  --> ",
        }
     ],
     msg = "An error occurred while quiescing the virtual machine. See the virtual machine's event log for details."
  }
  --> Args:
  --> Arg vmid:6
  --> Arg name:"clone-temp-1286776661914351"
  --> Arg description:
  "This temporary snapshot is taken as part of the clone operation. The temporary snapshot will be deleted once the clone operation is complete."
  --> Arg memory:false
  --> Arg quiesce:true
  
• The vmware.log of the virtual machine contains entries similar to:
  2010-10-10T23:02:12.050Z| vcpu-3| [msg.snapshot.quiesce.vmerr] The Guest OS has reported an error during quiescing.
  2010-10-10T23:02:12.050Z| vcpu-3| --> The error code was: 5
  2010-10-10T23:02:12.050Z| vcpu-3| --> The error message was: 'VssSyncStart' operation failed: IDispatch error #8449 (0x80042301)

Resolution

This issue occurs because the I/O in the virtual machine is high and the quiescing operation is unable to flush all the data to disk, while further I/O is created.

To resolve this issue, perform one of these options:

• Verify VSS, guest, and backup product configuration. For additional steps on troubleshooting VSS, seeTroubleshooting Volume Shadow Copy (VSS) quiesce related issues (1007696).
• Reduce the amount of ongoing I/O to the virtual machine. This can be accomplished using pre or post-freeze scripts to quiesce application I/O. For more information, see the Virtual Machine Backup Guide.
• Opt for a crash-consistent snapshot (as opposed to application-consistent) of the virtual machine by avoiding quiescing of the file system.

If you do not want to quiesce the virtual machine during the snapshot creation, there are several options. Choose one of these options, based on your environment: 

• If you are using VCB or a backup product that relies upon the VCB framework, see Quiescing Mechanisms in theVirtual Machine Backup Guide.
• If you are taking the snapshot manually in ESX/ESXi 4.x, deselect the Quiesce guest file system option in the vSphere Client. In ESX/ESXi 3.5 it is not possible to take quiescent snapshots from the VMware Infrastructure Client.
• If the snapshots are taken via the ESX host terminal using the vmware-cmd command, set the option of quiescing to 0.
  
  To set quiescing to 0, run the command:
  # vmware-cmd <cfg> createsnapshot <name> <description> <quiesce> <memory>
  
  For example:
  # vmware-cmd /vmfs/volumes/4adecc3a-62b367e8-5b15-001a4be960e0/VMname/VMname.vmx createsnapshot "Snap Name" "Snap Description" 0 0
  
• If you are using a 3rd party backup product that does not allow you to configure for non-quiescent snapshots, remove the VSS component from the Windows guest operating system, provided as part of VMware Tools. When a quiescent snapshot is requested, VMware Tools does not find and utilize the VSS driver and the attempts to quiesce the filesystem are not made. The /var/log/vmware/hostd.log file reports this incident, but the snapshot creation completes without error additional errors.
  
  Note: This requires a reboot of the virtual machine. VMware recommends scheduling downtime before performing this action.
• 1. Uninstall VMware Tools.
  2. Allow the system to reboot.
  3. Reinstall VMware Tools. Ensure to click Custom Install.
  4. Deselect VSS.
     
     After the installation, you are able to take a snapshot where the quiescing operation is not performed even if specifically requested.

Note: Older versions of Windows and guests deployed prior to VMware ESX 3.5 Update 2 utilize the Sync Driver, instead of VSS, for quiescent snapshot requests.

Manually update WSUS .msu file

A file with .msu extension is used to deliver Windows updates (security updates, critical updates, updates, update rollups or hotfixes) or downloadable setup packages to the Windows Vista and in Windows Server 2008 system.

msu stands for Microsoft Update Standalone Package. These files are associated with the Windows Update Stand-alone Installer (Wusa.exe) in Windows Vista and in Windows Server 2008. The Wusa.exe file is in the %windir%\System32 folder. The Windows Update Stand-alone Installer uses the Windows Update Agent API to install update packages.

An .msu file contains the following contents:

• Windows Update metadata
  This metadata describes each update package that the .msu file contains.
• One or more .cab files
  Each .cab file represents one update.
• An .xml file
  This .xml file describes the .msu update package. Wusa.exe uses the .xml file when you perform an unattended installation of the update by using the Package Manager tool (Pkgmgr.exe).
• A properties file
  This file contains string properties that Wusa.exe uses. For example, this file contains the name of the associated article in the Microsoft Knowledge Base.

To install an .msu update package, run Wusa.exe together with the full path of the file. For example, if the Windows6.0-KB952876-x86.msu file is in the C:\Temp folder, type the following command at a command prompt to install the update package:

wusa.exe C:\Temp\Windows6.0-KB952876-x86.msu

You can also double-click the .msu file to install the update package.

You can’t open the .msu file on a computer that is not running Windows Vista or Windows Server 2008. You cannot extract or view the MSU’s contents. To resolve this issue, use the Windows Vista Expand command to extract and to view the files in an MSU.
expand -f:* “C:\934307\Windows6.0-KB952876-x86.msu” %TEMP%

Then, you type the following command at a command prompt:

pkgmgr.exe /n:%TEMP%\Windows6.0-KB952876-x86.xml

VMware cluster load imbalance

Cluster Has Load Imbalance

A cluster might become unbalanced because of uneven resource demands from virtual machines and unequal capacities of hosts.

Possible reasons why the cluster has a load imbalance:

■	The migration threshold is too high: A higher threshold makes the cluster a more likely candidate for load imbalance.

■	VM/VM or VM/Host DRS rules prevent virtual machines from being moved.

■	DRS is disabled for one or more virtual machines.

■	A device is mounted to one or more virtual machines preventing DRS from moving the virtual machine in order to balance the load.

■

Virtual machines are not compatible with the hosts to which DRS would move them. That is, at least one of the hosts in the cluster is incompatible for the virtual machines that would be migrated. For example, if vMotion is disabled on host A, then host A becomes incompatible for powered-on virtual machines running on host B.

■	It would be more detrimental for the virtual machine's performance to move it than for it to run where it is currently located. This may occur when loads are unstable or the migration cost is high compared to the benefit gained from moving the virtual machine.

■	vMotion is not enabled or set up for the hosts in the cluster.

HDX Ready Thin Clients Technology

The most frequent question IT managers ask Citrix regarding Thin Clients is: “Which devices do you recommend with XenDesktop and XenApp?”  Citrix established the Citrix Ready framework to answer this question.  Citrix Ready is a verification program for partners to demonstrate interoperability between their products and Citrix products. The Thin Client category of Citrix Ready allows partners the option to test their devices to achieve basic Citrix Ready status or the more stringent HDX Ready status. These options are designed to address market needs based on end user segments and user experience requirements.

What is an HDX Ready Thin Client? 
The HDX Ready designation is reserved for thin client devices that have been verified to work with all of the XenDesktop and XenApp HDX features.  HDX refers to High Definition User eXperience – a term coined by Citrix to describe capabilities in XenDesktop that optimize the user experience when accessing hosted virtual desktops and applications. The HDX Ready category assists IT managers to easily identify thin client devices that deliver the best possible high definition user experience with XenDesktop and XenApp.  

What is a Citrix Ready Thin Client?
There is a trade-off between a thin client’s cost and its capabilities. Not all users require the functionality of all of HDX features of XenDesktop or XenApp.  Devices that are not deemed HDX Ready may still be useful for certain user types and use cases, generally at a lower price point than HDX Ready devices.  The Citrix Ready thin client designation exists for those devices that support connectivity to XenDesktop or XenApp but only a subset of HDX functionality.  Information regarding HDX feature coverage by a particular thin client device is available on the Citrix Ready website.