Friday, 29 January 2010

Storage VMotion with VI Remote CLI

This article provides steps to use Storage VMotion (SVMotion) to move virtual machines from one LUN to another LUN when you are using the VI Remote CLI

First install the VI Remote CLI, you can download it from the following locations.

If you are using Remote CLI on Windows, open a command prompt and browse to the bin directory inside C:\Program Files\VMware\VMware VI Remote CLI\.

Next run the following command to put svmotion in to interactive mode

C:\Program Files (x86)\VMware\VMware VI Remote CLI\bin> --interactive

once you have put svmotion in to interactive mode you will be prompted with the following
Entering interactive mode.  All other options and environment variables will be

Enter the VC url or IP address and add in a username and password with the correct rights to perform a svmotion
Enter the VirtualCenter service url you wish to connect to (e.g., or just
Enter your username: Domain\username
Enter your password: ********

wait for the CLI to connect to your VC
Attempting to connect to
Connected to server.

Enter the name of your VC.  Note: I noticed that this value needs to be case sensitive.
Enter the name of the datacenter: VM DataCenter

Enter the datastore path of the VM.  Note: This is also case sensitive.
Enter the datastore path of the virtual machine (e.g. [datastore1] myvm/myvm.vmx
): [LUN1] WIN2k3-Test/WIN2k3-Test.vmx

Enter the name of the destination datastore: LUN2

you will be prompted with the following message if you VM has multiple disks.
You can also move disks independently of the virtual machine.  If you want the disks to stay with the virtual machine, then skip this step..
Would you like to individually place the disks (yes/no)? no

Performing Storage VMotion.
0% |----------------------------------------------------------------------------
------------------------| 100%
Storage VMotion completed successfully.


your VM has now been svmotion across to its new LUN.

Also you can use SVMotion Graphical User Interface by Alexander Gaiswinke in conjunction with the VI Remote CLI as well if you are not comfortable with using the VI Remote CLI. 

Simply Install the VMWARE remote CLI on a Windows machine to the standard path.
Download the GUI and save the file into the C:\Program Files\VMware\VMware VI Remote CLI\bin directory.
Save the svmotionGUI.exe somewhere on the machine.
Double click it!

Thursday, 28 January 2010

Exchange Powershell Commands

Please check out for more of my technical posts, alternately please call us on 01932 268289. 

To gives full access permission to all the mailboxes 
Get-Mailbox | Add-MailboxPermission -AccessRights Fullaccess -User

To remove mailbox permissions
get-mailbox -server "servername" | remove-mailboxpermission -user Domain\Username_here -AccessRights "FullAccess"

Bulk imports Mail contacts in to Exchange2007 via a CSV file
Import-Csv c:\csv\book1.csv | ForEach { New-MailContact -Name $_.displayName -Firstname $_.FirstName -LastName $_.LastName -ExternalEmailAddress $_.Emailaddress -Alias $_.Alias -OrganizationalUnit "" }

This is the book1.csv file that was imported - look at the format
DisplayName FirstName LastName Emailaddress Alias OrganizationalUnit
Ted Smith (Internet) Ted Smith tedsmith

Get list of all mailboxes with all details and export to CSV file
Get-Mailbox | export-csv c:\csv\export.csv | Format-List

Get list of all Distribution Lists and export to CSV file
Get-DistributionGroup | export-csv c:\csv\DL.csv | FT Name, AddressListMembership

add full mailbox rights to a mailbox
Get-Mailbox -Identity server | Add-MailboxPermission -AccessRights fullaccess -User

to get a list of all users in a distribution list
Get-DistributionGroupMember -Identity "UK-Marketing Bulletin" | export-csv c:\DL.csv

to change the default search scope

To set the recipient scope to the Marketing Users OU in the domain, run the following command:
$AdminSessionADSettings.DefaultScope = " Users"

To set the recipient scope to the domain and use as the recipient domain controller, run the following commands:
$AdminSessionADSettings.DefaultScope = ""
$AdminSessionADSettings.PreferredDomainControllers = ""

To set the recipient scope to the entire forest and use as the global catalog server, run the following command:
$AdminSessionADSettings.ViewEntireForest = $True
$AdminSessionADSettings.PreferredGlobalCatalog = ""

Test Outlook Web Services for a certain user and output them in to a DOS box
Test-OutlookWebServices -I | fl

To check wheather a group has sender auth enabled
Get-DistributionGroup “Group? | Select-Object Name, RequireSenderAuthenticationEnabled

to disabled sender auth
Set-DistributionGroup “Group? -RequireSenderAuthenticationEnabled $False

Get Transport Servers full details exported to a CSV file
Get-TransportServer | export-csv c:\will.csv | Format-List

Add a user as a public folder admin
Add-ExchangeAdministrator -Identity '' -Role:'PublicFolderAdmin'

Get-Mailbox | Get-MailboxStatistics | select DisplayName,TotalItemSize| sort TotalItemSize | export-csv c:\filename.csv

Get a list of all SMTP address of all users.
Get-Mailbox | select -expand EmailAddresses | %{$_.SmtpAddress}

Get a list of currently logged on users
Get-LogonStatistics -Server SRV | export-csv c:\export.csv | Format-List

Get details of managed by in email distribution list
Get-DistributionGroup | fl displayname, managedby

Get full details of any mailbox with certain words in it.
get-mailbox *word* | fl

Give a user full rights over public folders

Add-PublicFolderAdministrativePermission -User username -Identity \PublicFolder -AccessRights AllExtendedRights

Get Cluster Information
Running a cluster res from CMD will show which Exchange Server is the current node in the cluster. 

running a cluster group "Cluster Group" /moveto:ExchSrv01 will move the cluster back to ExchSrv01. 

How to find out what server is accepting RPC Connection
get-mailboxdatabase | ft name,RpcClientAccessServer

Change which server a Mailbox with user for RPC connections.
Set-mailboxdatabase -Identity lonmbx1 -RpcClientAccessServer ""

Public Folder cmdlets:

Archive in Exchange 2010

Extensible Storage Engine (ESE) explained

Extensible Storage Engine (ESE)

The core storage technology of Microsoft Exchange Server and Active Directory is called Exchange Extensible Storage Engine (ESE), also known as JET Blue. It is an Indexed Sequential Access Method (ISAM) data storage technology whose purpose is to allow applications to store and retrieve data via indexed and sequential access. Window Mail and Desktop Search in the Windows Vista operating system also makes use of ESE to store indexes and property information respectively.

To highlight basic features of ESE –

  • Microsoft JET is an advanced 32-bit multithreaded database engine that combines speed and performance with other advanced features to enhance transaction-based processing capabilities.
  • A crash recovery mechanism is provided so that data consistency is maintained even in the event of a system crash.
  • Transactions in ESE are highly concurrent, making ESE suitable for server applications. ESE caches data intelligently to ensure high performance access to data.
  • In addition, ESE is lightweight making, optimized for fast data storage and retrieval.

The ESE Runtime (ESENT.DLL) has shipped in every Windows release since Windows 2000, with the native x64 version of the ESE runtime shipping with x64 versions of Windows XP and Windows Server 2003. The 64 bit edition support started with Exchange 2007; up to Exchange 2003, ESE runtime was shipped with only the 32 bit edition.

Exchange Information Store

The information store, which is the key component for database management in Exchange Server, is actually two separate databases. The private information store database, Priv.edb, manages data in user mailboxes. The public information store, Pub.edb, manages data in public folders.

Private store consist of .edb and .stm files. The .edb file is the main repository for the mailbox data. The .edb file is accessed by ESE directly. The fundamental construct of the .edb file is the b-tree structure. The ESE 4 KB pages are arranged into tables that form a large database file containing Exchange data.

The .stm or streaming media file is used in conjunction with the .edb file to comprise the Exchange database. Both files together make up the database, and as such, they should always be treated as a single entity.
The information store works with the Messaging Application Programming Interface (MAPI) and the database engine to ensure that all user actions are recorded on the server's hard disk.

ESX 4.0 and ESXi 4.0 shutdown and reboot commands

Please check out for more of my technical posts, alternately please call us on 01932 268289. 

When virtual machines are running, ESX might not clear the RAID controller's cache if you shut down or reboot ESX host by using the following commands on the service console:

  • reboot -f 
  • halt
  • shutdown

You can shut down or reboot ESX 4.0 or ESXi 4.0 hosts using any of the following methods:

ESX 4.0
Log in to the ESX service console and perform one of the following steps from the service console to shutdown or reboot ESX 4.0 hosts.

Run the shutdown –r now command to reboot the system.
Note: This command shuts down the virtual machines running on the ESX 4.0 hosts.
Run the reboot command to reboot the system.
Run the poweroff command to shut down ESX. After the shutdown, a message indicates that it is safe to power off your system. Press the power button until the machine powers off. You can then manually reboot the system.

ESXi 4.0
In the console screen of the ESXi 4.0 host, press Ctrl+Alt+F2 to see the Direct Console User Interface (DCUI) screen.
In the DCUI screen, press F12 to view the shutdown related options for the ESXi host.
Press F2 to shut down.
Press F11 to reboot.

ESX 4.0 or ESXi 4.0
From vSphere Client
Before shutting down or rebooting the ESX 4.0 or the ESXi 4.0 hosts, ensure that the hosts are put in maintenance mode. Powering off a managed host disconnects it from vCenter Server, but does not remove it from the inventory.
Shut down or VMotion all virtual machines running on ESX 4.0 or ESXi 4.0 hosts.
Put the ESX 4.0 or ESXi 4.0 hosts in the maintenance mode.
Select the ESX 4.0 or the ESXi 4.0 host you want to shut down.
Right-click the ESX 4.0 or the ESXi 4.0 host that you want to shut down, and select Reboot or Shut Down.
If you select Reboot, the ESX 4.0 or the ESXi 4.0 host shuts down and reboots.
If you select Shut Down, the ESX 4.0 or the ESXi 4.0 host shuts down. You must manually power the system back.
Provide a reason for the shut down or reboot. This information is added to the log.

From vCLI or vMA
To put ESX 4.0 or ESXi 4.0 hosts in the maintenance mode, run the following command from vMA (vSphere Management Assistant) or vCLI (vSphere Command-Line Interface) console screen:

/usr/lib/vmware-vicli/apps/host/ --target_host --operation enter_maintenance --url https:///sdk/vimService.wsdl 

To reboot ESX 4.0 or ESXi 4.0 hosts, run the following command from vMA or vCLI console screen:

/usr/lib/vmware-vicli/apps/host/ --target_host --operation reboot --url https:///sdk/vimService.wsdl 

To shut down ESX 4.0 or ESXi 4.0 hosts, run the following command from vMA or vCLI console screen:

/usr/lib/vmware-vicli/apps/host/ --target_host --operation shutdown --url https:///sdk/vimService.wsdl 

Exchange Autodiscover

When Microsoft released Exchange Server 2007, one of the new features it included was Autodiscover. Autodiscover allows you to automatically configure Outlook 2007 clients, but, there is a lot more behind the Autodiscover functionality. When you have issues with the Out-of-Office or Free/Busy information in Outlook 2007 in combination with Exchange Server 2007 (or Outlook 2010 and Exchange Server 2010) it is likely that it is caused by a misconfiguration in the Autodiscover configuration. To make things more complex, the SSL certificates are involved here as well.

The Autodiscover process for Exchange 2007 and Outlook 2007 is practically the same as for Exchange 2010 and Outlook 2010. In this article I will use Exchange 2010 and Outlook 2010.

Autodiscover information is stored in a so called SCP or Service Connection Point. You can view this SCP using Active Directory Sites and Services after you have enabled the “View Services Node” option.

When installing the Client Access Server (Autodiscover is part of this Server Role) the SCP is automatically created in Active Directory and configured with the default values. If you have multiple CAS Servers there will be multiple SCP’s as well.

When Outlook 2007 is installed on a domain joined workstation then the Outlook client will query Active Directory for the Autodiscover information. Active Directory will return a list of SCP’s and the Outlook client will automatically select the first SCP in this list. Using the information found in the SCP the Outlook client will contact the Client Access Server for its configuration information and the Outlook client will be configured automatically.

Non-domain clients are a bit trickier to configure since they will not query the Active Directory. Because of this non-domain clients try to retrieve information using the Autodiscover website. The FQDN that the Outlook client will use is based on the SMTP address that is used when starting the Outlook 2010 client the first time. So, when an e-mail address is entered, the Outlook client will start trying to connect to the Client Access Server using HTTPS. There are several URL’s that Oulook will use, but the most important is

Please be aware that this is the (Internet facing) Client Access Server. So besides the normal Outlook Web Access URL like the same Client Access Server is also contacted using  This is exactly the reason a Unified Communications (UC) or SAN certificate is needed. 

Note: You can actually use a single certificate for for both OWA and Outlook Anywhere.  Please see my other blog on SSL for both OWA and Outlook Anywhere

Besides the possibility to configure Outlook 2007 and higher clients using the Autodiscover process there’s more information, in this process.
  • Out-of-Office information
  • Availability Services
  • Offline Address Book download information
  • Unified Messaging information
  • Exchange 2010 personal archive (for Outlook 2010 clients only)
In Exchange Server 2010 the properties related to these settings are configured during setup of the Client Access Server when entering the “this is an external facing Client Access Server” option. When you do not select this option, or in Exchange Server 2007 you have to configure these properties manually using the Exchange Management Shell:

Set-OWAVirtualDirectory –Identity 2K10HUBCAS02\OWA (default web site) 

Set-OABVirtualDirectory –Identity 2K10HUBCAS02\OAB (default web site) 

Set-WebServicesVirtualDirectory –Identity 2010CASUB02\EWS (default web site) -ExternalURL

Set-ActiveSyncVirtualDirectory –Identity 2K10HUBCAS02\Microsoft-Server-ActiveSync (default web site) 

This setting is only valid for Exchange Server 2010:

Set-ECPVirtualDirectory –Identity 2K10HUBCAS02\ECP (default web site) 

The last step is to configure the external DNS for both the webmail hostname as well as the Autodiscover hostname as they need to point to the external facing Client Access Server.

When you start up Outlook 2007/2010 you can automatically configure your profile, If all goes well you should be able to set your out-of-office settings and check other mailboxes free/busy information.

If you want to check that this is working correctly you can start Outlook and you will see the small Outlook icon in the system tray. Press the Control key together with a right mouse click, there you have two options:
  • Connection Status
  • Test E-mail AutoConfiguration
The connection status shows the various connections that are initiated between the Outlook client and the Exchange server. 
With the ‘Test E-mail AutoConfiguration’ there is the possibility to test the Autodiscover configuration.  Fill in your e-mail address and password, and to check the Autodiscover functionality only deselect the “Use Guessmart” and “Secure Guessmart Authentication”. When you click Test the Outlook client will check the full Autodiscover functionality and the results will be shown on the Results tab.

Another way, especially when troubleshooting your Autodiscover configuration, is the Remote Analyzer that is available on the Internet. Go on to This site is developed by a few guys from the Microsoft Exchange Product Team. This site can help you troubleshoot all kinds of remote connectivity issues and gives detailed results after checking.

Wednesday, 27 January 2010

Exchange 2010 Database Availability Groups (DAG)

Please check out for more of my technical posts, alternately please call us on 01932 268289. 

With Exchange 2010, we no longer have the concept of Local Continuous Replication (LCR), Single Copy Clusters (SCC), Cluster Continuous Replication (CCR) or Standby Continuous Replication (SCR), well this is not entirely true only LCR and SCC have been removed from the Exchange Server product. CCR and SCR have been combined and have evolved into a more unified high availability framework in which the new Database Availability Group (DAG) act as the base component. This means that no matter if you are going to deploy a local or site-level highly available or disaster recoverable solution, you use a DAG. 

So what’s interesting about a DAG then?

Limited dependency on Windows Failover Clustering - A DAG only uses a limited set of the clustering features provided by the Windows Failover Clustering component. DAG uses the cluster database, heartbeat, and file share witness functionality.

Incremental deployment - Because DAGs still use some of the WFC components such as the cluster database, heartbeat and file share witness functionality, Windows Server 2008 SP2 or R2 Enterprise edition is required in order to be able to configure Exchange 2010 Mailbox servers in a DAG. But Exchange 2010 supports an incremental deployment approach meaning that you don’t need to form a cluster prior to installing Exchange 2010. You can install the Exchange 2010 Mailbox servers, and then create a DAG and add the servers and any databases to the DAG when needed.

Co-existence with other Exchange roles - With CCR you could not install other Exchange Server roles on the mailbox servers (cluster nodes) that were protected using CCR. With DAG, a mailbox server part of a DAG can have other Exchange roles installed. This is especially beneficial for small organizations. Because now that a DAG protected Mailbox server can co-exist with other Exchange roles, it also means that you can have a fully redundant Exchange 2010 solution with only two machines dedicated as Exchange servers. Of course, you need to configure a file share witness, but this could be any in your environment.

Managed 100% via Exchange tools - With CCR in Exchange 2007, you had to configure and manage CCR clusters using a combination of Exchange and cluster management tools. With DAGs in Exchange 2010, you no longer need to use cluster management tools for either the initial configuration or management. You can manage DAGs fully using the Exchange Management tools. 

Replication at the database level - In order to support the new DAG feature, databases in Exchange 2010 has now been moved to the organizational level instead of the server level where they existed in Exchange 2007 and earlier versions. This also means Exchange 2010 does not have the concept of storage groups any longer. Now there are databases and a log stream associated with each database. One drawback of CCR was that if only one database failed on the active node, a fail-over of all active databases existing on the clustered mailbox server were moved to the passive CCR node. This meant that all users on that had a mailbox stored on the respective CMS were affected.

Support for up to 16 members in each DAG - Now that you can add up to 16 Mailbox servers to a DAG and potentially have 16 copies of each Mailbox database, Exchange 2010 had to support a larger number of mailbox databases than Exchange 2007 did. So the maximum limit has now been upped from 50 to 100 Mailbox database in the Exchange 2010 Enterprise edition. However, the Standard edition still only supports up to 5 databases per Mailbox server.
Switch/Fail-overs much quicker than in the past - Because of the improvement made with Exchange 2010 DAG, we will now experience much quicker switches and fail-overs (*-overs) between mailbox database copies. They will typically occur in under 30 seconds, compared to several minutes with CCR in Exchange 2007. In addition, because Outlook MAPI clients now connect to the RPC Client Access service on the Client Access Servers, end users will rarely notice a *-over occurred. You can read more about the RPC Client Access service in a previous articles series of mine here.
Go backup-less with +3 DB copies - When having 3 or more copies of a mailbox database, it is programmed to backup-less. This means that you basically enable circular logging on all mailbox databases protected by DAG, and no longer perform backups as we know them. This thinking of course requires enterprise organizations to change their mindset in regards to how they think mailbox databases should be protected.
Support for DAG members in separate AD sites - Unlike CCR cluster nodes, you can have DAG member servers located in different Active Directory sites. This should be a welcome addition to those of you who do not have the option of using the same AD site across physical locations (datacenters). It should be noted though, that you cannot place Mailbox servers protected by the same DAG in different domains within your Active Directory forest.
Log shipping via TCP - In Exchange 2007, the Microsoft Exchange Replication Service copied log files to the passive database copy (LCR), passive cluster node (CCR) or SCR target over Server Message Block (SMB), which meant you needed to open port 445 in any firewall between the CCR cluster nodes (typically when deploying multisite CCR clusters) and/or SCR source and targets. Those of you who work for or with a large enterprise organization know that convincing network administrators to open port 445/TCP between two datacenters is far from a trivial exercise. With Exchange 2010 DAG, the asynchronous replication technology no longer relies on SMB. Exchange 2010 uses TCP/IP for log file copying and seeding and, even better, it provides the option of specifying which port you want to use for log file replication. By default, DAG uses port 64327, but you can specify another port if required.
Log file compression - with Exchange 2010 DAGs you can enable compression for seeding and replication over one or more networks in a DAG. This is a property of the DAG itself, not a DAG network. The default setting is InterSubnetOnly and has the same settings available as those of the network encryption property.
Log file encryption - Exchange 2010 DAG supports the use of encryption whereas log files in Exchange 2007 are copied over an unencrypted channel (unless IPsec has been configured). More specifically, DAG leverages the encryption capabilities of Windows Server 2008—that is, DAG uses Kerberos authentication between each Mailbox server member of the respective DAG. Network encryption is a property of the DAG itself, not the DAG network. Settings for a DAG's network encryption property are: Disabled (network encryption not in use), Enabled (network encryption enabled for seeding and replication on all networks existing in a DAG), InterSubnetOnly (the default setting meaning network encryption in use on DAG networks on the same subnet), and SeedOnly (network encryption in use for seeding on all networks in a DAG).
Up to 14 day lagged copies - With Standby Continuous Replication which were included in Exchange 2007 SP1, the concept of lagged database copies were introduced. With this feature we could delay the time for when log files that were copied to the SCR target should be replayed into the databases on the SCR target. We also had the option of specifying a so called truncation lag time, which was an option which allowed us to delay the time for when log files that had been copied to the SCR target and replayed into the cop of the database should be truncated. With both options we could specify a lag time of up to 7 days. With Exchange 2010 DAG, we can now specify a truncation lag time of up to 14 days, which is extra interesting when you choose to go backup-less.
Seeding from a DB copy - Unlike CCR in Exchange 2007, we can now perform a seed by specifying a database copy as the source database. This means that a new seed or a re-seed of an existing mailbox database no longer has any impact on the active database copy.
Improved Transport Dumpster - The transport dumpster we know from Exchange 2007 has also been improved, so that messages are re-delivered even when a lossy database failover occurs between databases copies stored in different Active Directory sites. In addition to this, when all messages have been replicated to all database copies, they will be deleted from the transport dumpster.
I thought i'd better make it aware that you cannot use DAG on a PF database.  Public folder databases must be protected using traditional public folder replication mechanisms. The positive thing about this is that we no longer are limited to only one public folder store in the Exchange organization, if it is stored on a DAG member server.

Helpful ESX 3.5 & VC 2.5 links

Compatibility & Version Info:
VI3 Key Features & Benefits Summary by Version -
VMware Infrastructure Compatibility Matrixes -
Details of What's New and Improved In VI3 Version 3.5 -

Release Notes/Install, Upgrade and Patch Guide:
ESX Server 3.5 and VirtualCenter 2.5 Release Notes -
ESX Server 3 Installation Guide -
Upgrade Guide -
ESX Server 3 Patch Management Guide -

Additional documentation:
Configuration Maximums for VMware Infrastructure 3 -
Quick Start Guide -
Basic System Administration -
Virtual Infrastructure Web Access Administrator's Guide -
ESX Server 3 Configuration Guide -
Resource Management Guide -
Fibre Channel SAN Configuration Guide -
iSCSI SAN Configuration Guide -
Virtual Machine Backup Guide -
VMware Infrastructure 3 Primer -

VMware Converter Enterprise for VirtualCenter 2.5 Admin Guide -
VMware Converter Enterprise for VirtualCenter 2.5 Release Notes -

Update Manager:
VMware Update Manager Release Notes -
VMware Update Manager Admin Guide -
VMware Update Manager Sizing Estimator -

Helpful ESX Commands

# cd /var/run/vmware
Navigate to the /var/run/vmware directory
vdh -h
will show you all the partitions including those being controlled by the VMKernel.
Esxcfg-vswitch Description: Creates and updates virtual machine (vswitch) network settings
Syntax: esxcfg-vswitch [vswitch[:ports]]

-a Add a new virtual switch.
-d Delete the virtual switch.
-l List all the virtual switches.
-L Set pnic as an uplink for the vswitch.
-U Remove pnic from the uplinks for the vswitch.
-p Specify a portgroup for operation.
Use ALL for operation to work on all portgroups
-v Set VLAN ID for portgroup specified by
-p. 0 would disable the VLAN.
-c Check to see if a virtual switch exists. Program outputs a 1 if it exists, 0 otherwise.
-A Add a new portgroup to the virtual switch.
-D Delete the portgroup from the virtual switch.
-C Check to see if a portgroup exists. Program outputs a 1 if it exists, 0 otherwise.
-r Restore all virtual switches from the configuration file (Internal use only)
-h Displays command help

esxcfg-vswitch examples:
Add a pnic (vmnic2) to a vswitch (vswitch1): esxcfg-vswitch -L vmnic2 vswitch1.
Remove a pnic (vmnic3) from a vswitch (vswitch0): esxcfg-vswitch -U vmnic3 vswitch0.
Create a portgroup (VM Network3) on a vswitch (vswitch1): esxcfg-vswitch -A "VM Network 3" vSwitch1 Assign a VLAN ID (3) to a portgroup (VM Network 3) on a vswitch (vswitch1): esxcfg-vswitch -v 3 -p "VM Network 3" vSwitch1.
NOTE: Port group Names are CaSe SenSiTive

Description: Creates and updates service console network settings. This command is used if you cannot manage the ESX Server host through the VI Client because of network configuration issues.
Syntax: esxcfg-vswif [vswif]

-a Add vswif, requires IP parameters. Automatically enables interface.
-d Delete vswif. -l List configured vswifs.
-e Enable this vswif interface.
-s Disable this vswif interface.
-p Set the portgroup name of the vswif.
-i or DHCP The IP address for this vswif or specify DHCP to use DHCP for this address.
-n The IP netmask for this vswif.
-b The IP broadcast address for this vswif. (not required if netmask and ip are set)
-c Check to see if a virtual NIC exists. Program outputs a 1 if the given vswif exists, 0 otherwise.
-D Disable all vswif interfaces. (WARNING: This may result in a loss of network connectivity to the Service Console)
-E Enable all vswif interfaces and bring them up.
-r Restore all vswifs from the configuration file. (Internal use only)
-h Displays command help. Note: You can set the Service Console default gateway by editing the /etc/sysconfig/network file or through the VI Client under Configuration, DNS & Routing.

esxcfg-vswif examples:
Change your Service Console (vswif0) IP and Subnet Mask: esxcfg-vswif -i -n vswif0 Add a Service Console (vswif0): esxcfg-vswif -a vswif0 -p "Service Console" -i -n

Description: Sets or retrieves the default VMkernel gateway route Syntax:
esxcfg-route can be specified in 2 ways: as a single argument in / format or as a pair. is either an IP address or 'default'

-a Add route to the VMkernel, requires network address (or 'default') and gateway IP address.
-d Delete route from the VMkernel, requires network address (or 'default').
-l List configured routes for the Service Console.
-r Restore route setting to configured values on system start. (Internal use only)
-h Displays command help
esxcfg-route examples:
Set the VMkernel default gateway route: esxcfg-route
Add a route to the VMkernel: esxcfg-route -a default
Description: Creates and updates VMkernel TCP/IP settings for VMotion, NAS, and iSCSI
Syntax: esxcfg-vmknic [[portgroup]]

-a Add a VMkernel NIC to the system, requires IP parameters and portgroup name.
-d Delete VMkernel NIC on given portgroup.
-e Enable the given NIC if disabled.
-D Disable the given NIC if enabled.
-l List VMkernel NICs.
-i The IP address for this VMkernel NIC. Setting an IP address requires that the -n option be given in same command.
-n The IP netmask for this VMkernel NIC. Setting the IP netmask requires that the -
i option be given in the same command.
-r Restore VMkernel TCP/IP interfaces from configuration file. (Internal use only)
-h Displays command help

esxcfg-vmknic examples:
Add a VMkernel NIC and set the IP and subnet mask: esxcfg-vmknic -a "VM Kernel" -i -n
Description: Configures the service console firewall ports Syntax: esxcfg-firewall

-l Lists current settings -q Lists settings for the specified service
-q incoming|outgoing Lists settings for non-required incoming/outgoing ports
-s Lists known services -l Loads current settings
-r Resets all options to defaults
-e Allows specified service through the firewall (enables)
-d Blocks specified service (disables)
-o Opens a port
-c Closes a port previously opened by
-h Displays command help
-blockincoming Block all non-required incoming ports (default value)
-blockoutgoing Block all non-required outgoing ports (default value)
vmware-cmd –l
Description: Useful for use with ALL vmware-cmd commands which require the path to the VMX file to run successful
vmware-cmd –l examples

vmware-cmd stop vmware-cmd reset
Description: where hard, soft or trysoft specifies the behavior of the power operation . If is not specified, the default behavior is soft.
For more information, see the VMware Scripting API User's Manual.
vmware-cmd stop/start examples
vmware-cmd /vmfs/volumes/48ce49a0-6fc41293-9781-001f296bdb5d/VM1/VM1.vmx stop
service mgmt-vmware restart
Description: For troubleshooting purposes, it may be necessary to restart the management agents on your ESX 

Viewing logs from your ESX Server.
add one of the following commands to view any logs on a ESX server :tail, more, less, cat and grep.
Examples: more /var/log/vmkernel
NOTE: you can also use WinSCP ( ) to browse your ESX server folders in a "Windows Explorer Like" style and open log files with its file editor or you can copy them to a PC and open them with your favorite editor.
Service Console Commands

/proc/vmware/vm//mem/minReading from this file reports the minimum memory size in megabytes for the virtual machine identified by .
Writing a number  to this file changes the minimum memory size for the virtual machine identified by  toMB.
/proc/vmware/vm//mem/sharesReading from this file reports the number of memory shares allocated to the virtual machine identified by .
Writing a number  to this file changes the number of memory shares allocated to the virtual machine identified by to . The valid range of numerical values for  is 0 to 100000. You may also use the special values low,normal and high. These values are automatically converted into numbers, through the configuration optionsMemSharesPerMBLowMemSharesPerMBNormal and MemSharesPerMBHigh, described below.
Note that a value of zero (0) shares causes the virtual machine memory size allocation to be exactly equal to its specified minimum size, even if excess memory is available.
/proc/vmware/vm//mem/statusReading from this file reports current status information for the virtual machine identified by , including the specified shares, minimum size and maximum size parameters as well as the virtual machine name, current status, whether the virtual machine is currently waiting for memory to be reserved, current memory usage, current target size, memory overhead for virtualization and the amount of allocated memory actively in use. All memory sizes are reported in kilobytes.
/proc/vmware/sched/memReading from this file reports the memory status information for all non-system virtual machines in the entire system as well as several aggregate totals.
Writing the string realloc to this file causes an immediate memory reallocation. Memory is normally reallocated periodically every MemBalancePeriod seconds. (See /proc/vmware/config/MemBalancePeriod below for more information.) Reallocations are also triggered by significant changes in the amount of free memory.
/proc/vmware/memReading from this file reports the maximum size with which a new virtual machine can be powered on, admission control status including the amount of unreserved memory and unreserved swap space and the current amount of free memory in the system.
/proc/vmware/pshare/statusReading from this file reports various detailed statistics about the current status of transparent page sharing.
/proc/vmware/swap/statsReading from this file reports various detailed swap statistics.
/proc/vmware/config/MemSharesPerMBLowThis option specifies the a numerical value for the low shares value. By default, this number is 5.This number is multiplied by the virtual machine's maximum memory size to obtain the number of shares.
/proc/vmware/config/MemSharesPerMBNormalThis option specifies the a numerical value for the normal shares value. By default, this number is 10. This number is multiplied by the virtual machine's maximum memory size to obtain the number of shares.
/proc/vmware/config/MemSharesPerMBHighThis option specifies the a numerical value for the high shares value. By default, this number is 20. This number is multiplied by the virtual machine's maximum memory size to obtain the number of shares.
/proc/vmware/config/MemBalancePeriodThis ESX Server option specifies the periodic time interval, in seconds, for automatic memory reallocations. Reallocations are also triggered by significant changes in the amount of free memory. The default is 15 seconds.
/proc/vmware/config/MemSamplePeriodThis ESX Server option specifies the periodic time interval, measured in seconds of virtual machine virtual time, over which memory activity is monitored in order to estimate working set sizes. The default is 30 seconds.
/proc/vmware/config/MemIdleTaxThis ESX Server option specifies the idle memory tax rate as a percentage. A tax rate of x percent means that up to xpercent of a virtual machine's idle memory may be reclaimed. Virtual machines are charged more for idle memory, than for memory that they are actively using. A tax rate of 0 percent defines an allocation policy that ignores working sets and allocates memory strictly based on shares. A high tax rate results in an allocation policy that allows idle memory to be reallocated away from virtual machines that are unproductively hoarding it, regardless of shares. The default is 75 percent.
/proc/vmware/config/MemShareScanVMThis ESX Server option specifies the maximum per-virtual machine rate at which memory should be scanned for transparent page sharing opportunities. The rate is specified as the number of pages to scan per second. The default is 50 pages per second per virtual machine.
/proc/vmware/config/MemShareScanTotalThis ESX Server option specifies the total systemwide rate at which memory should be scanned for transparent page sharing opportunities. The rate is specified as the number of pages to scan per second. The default is 200 pages per second.
/proc/vmware/config/MemCtlMaxPercentThis ESX Server option limits the maximum amount of memory that may be reclaimed from any virtual machine usingvmmemctl, based on a percentage of its maximum size. Specifying 0 effectively disables reclamation via vmmemctl for all virtual machines. Defaults to 50.
/proc/vmware/config/MemCtlMax[OSType]These ESX Server options restrict the maximum amount of memory that may be reclaimed from a virtual machine usingvmmemctl, based on the limitations of guest operating system type. The value is specified in megabytes. Defaults to 128 for OSType=NT4 (Windows NT 4.0), 2048 for OSType=NT5 (Windows 2000 or Windows Server 2003), and 768 forOSType=Linux.

Good ESX logs to check

cat /var/log/vmware/vpx/vpxa.log