Ads 468x60px

Setting up the ESXi 5.0 Dump Collector



A core dump is the state of working memory in the event of host failure. By default, a core dump is saved to the local disk.  In the case of Auto Deploy where there may not be a local disk the core dump will be saved to a ramdisk in memory, which is a problem because the core dumps will be lost when the host reboots.


To solve this dilemma vSphere 5.0 includes a new feature called the ESXi Dump Collector.  The Dump Collector enables you redirect ESXi host core dumps onto a network server.  It’s very easy to install and configure.  The dump collector is included as part of the vCenter Server Appliance (VCSA) and requires no extra setup.  To install the dump collector on Windows simply load the vCenter installation media, launch autorun and from the main install menu choose “ESXi Dump Collector”.
A-dump-collector
During the install you will be asked where on the host you want to store the core dumps, by default the dump repository is 2GB, which should be sufficient for most environments.
Aa
You will also be asked if you want to do a Standalone installation or integrate the dump collector with  vCenter.  If you choose the VMware vCenter Server Installation it will register the Dump Collector plug-in with the vCenter server.
Ab
The final step is to use the ESXCLI to configure each host to use the Dump Collector.  The screen shot below shows the commands to do this.
Ac
Now anytime your ESXi 5.0 host generates a core dump the file will be saved on the network server and available for analysis.  The screen shots below show the file being copied to the network server when my ESXi host PSODs.  I also provided a listing of the corefile for reference.
A-PSOD
A-vcsa-dump

vSphere Syslog Collector – Install and Configure

I've always used vi-logger from within the vSphere Management Assistant to deal with my syslogging of our ESXi servers, that is until our last upgrade to vSphere 5.  The vi-logger command is no more within the 5.0 version of the VMA so I began looking from some alternate solutions.  Now I could of went out and used a Kiwi product or Splunk or configured a Linux box to do our syslogging, however I thought i would give the vSphere Syslog Collector that is bundled with the vCenter installation media a shot.  Honestly I don't find syslog to be a real science.  You centralize the log files, not a big deal, but having a solution all from one vendor is kind of nice.  The vSphere Syslog Collector does exactly what it says; it collects the log files from the ESXi hosts, but it also gives you some status information from within a vCenter plugin as well.  As well, it's a pretty easy install and config as you will see below.
First off mount the ISO of the vCenter installer on the server you would like to act as your collector and select 'VMware Syslog Collector' and click 'Install'.  During the install (and in VMware's documentation) it is called the vSphere Syslog Collector, however on the menu it's called the VMware Syslog Collector.  Let's just say VSC for short to cover off both names…
After accepting the EULA and licensing you should be presented with the Destinations screen.  Here we need to do a couple of things; First, select where you want the collector application to be installed and secondly, where the logs that are collected are going to be stored (Repository directory).  Also, we have the option here to chose how large we want the log files to grow as well as the number of rotations to keep.  I left all of these values at their defaults, except for the repository directory as I wanted to place this on some lower level, cheaper storage.
Next we need to chose a setup type.  I chose to go with VMware vCenter Server installation as I wanted to integrate this with my vCenter instance. Otherwise, you can chose the 'Standalone Installation' option.  
After selecting your setup type, if choosing to integrate with vCenter you will need to provide login credentials to your vCenter Server.  For the most part this should be pretty straightforward.
Next up is ports and protocols.  Again, I left all of these at default, however you may wish to change the ports that the syslog collector operate on.
Then it's just matter of specifying how it should be defined on the network and letting it install…
So that's it, the collector is now installed.  One more step, we need to tell the desired hosts where we want to ship their logs to.  This can be done in a few different ways, all accomplishing the same thing, but, to each his own, here are the methods that I'm aware of.
1. The GUI – for the non command line type people.
Select your desired host which you want to syslog.  Go to Configuration->Advanced Settings (under Software)->Syslog->Global.  From here it is as simple as setting the hostname or IP address of your syslog server in the syslog.Global.LogHost option.
***Updated April 2012***
Also, be sure to open up the syslog ports within the firewall built into ESXi itself.  Go to Configuration->Security Profile and click 'Properties' in the Firewall section.  It can be as simple as just checking the box next to syslog, however if you would like to further secure your environment you can click the 'Firewall' button at the bottom and specify which IP address/networks are allowed to connect through these ports.

2. The ESXi Command Line space
Using the following two commands you can do the exact same thing as explained in #1.
esxcli system syslog config set –loghost=vCenter01
esxcli system syslog reload
Updated - And the firewall commands to open up the correct ports and restrict access to your syslog server.
esxcli network firewall ruleset set –ruleset-id=syslog –enabled=true –allowed-all=false
esxcli network firewall ruleset allowedip add –ruleset-id syslog –ip-address 192.168.42.150
3. Host Profiles 
For those with larger installations, you can certainly set the syslog information in a host profile and remediate that against your hosts.  Those setting are located within the profile under the 'Advanced Configuration Option and the same 'Syslog.Global.logHost' option.  *** NOTE*** Until you actually create a host profile from a host that has already had this advanced option setup you will not see this option'.
Updated 
As well, don't forget to set the firewall options for your syslog server in the host profile under the Firewall Configuration -> Ruleset Configuration ->syslog – Ruleset section.
4. PowerCLI
Things begin to get a little fuzzy here.  If you try to run the get and set VMHostSyslogServer cmdlets on ESXi 5 you will receive an error stating that the host isn't supported for those cmdlets, however, they still work, they still setup the syslog server.  The proper way to do this through powershell is using the get and set VMHostAdvancedConfiguration cmdlets examples below.  And once again, I found even this to be a bit quirky in the sense that I couldn't get the set-VMHostAdvancedConfiguration to just accept a -Name and -Value for the setup, but had to use the -NameValue pairing instead.  Also I'm sure someone that knows powershell (not me :) ) can rock this out on one line, but for now, this is what I got.
$sysloginfo = get-VMHostAdvancedConfiguration -Name "syslog.Global.logHost-VMhost "IP of host that is already setup"
Set-VMHostAdvancedConfiguration -VMHost "IP of host you want to setup" -NameValue $sysloginfo
Updated
As for enabling the syslog in the firewall that can be achieved with the following command
Get-VMHostFirewallException -VMhost hostname -name syslog | Set-VMHostFirewallException -Enabled $true
But when it comes to setting the allowed IP I cannot for the life of me find a way to do this…I'll update later if I do, or if you do, please let me know in the comments. :)
So there you have it!  A fully functional instance of the vSphere Syslog Collector.  As always comments, questions, concerns, rants – put'em in the comments :)

Remove Windows Search version 4 from XP & 2003, try the following steps:


  1. Start by running up Add & Remove Programs from the control panel and look for Windows Desktop Search in the list. Unlike with version 3, Windows Search v4 should be there.
  2. If not, open a cmd window (click on Start, then “Run..” and type cmd in the Run dialogue that then appears). Then copy and paste the following line into the cmd window:
    %systemroot%\$NtUninstallKB940157$\spuninst\spuninst.exe
  3. If that also fails and you get a “The system cannot find the path specified.” error, then I have zipped up a copy that you can download from here. To work out where to extract it to, type:
    echo %systemroot%
    into your cmd window and note the location it points to (it is likely to be C:\Windows, but may not be if you upgraded to XP for Windows 2000 for example). Open the zip file, and extract the $NtUninstallKB940157$ to this location. Now repeat step 2.
Update: Thanks to “Derek” for pointing out to me that I’d missed the “bleedin’ obvious”, ie that v4 can be removed via “Add Remove Programs”. I’ve added this as step 1 as a consequence. Steps 2 and 3 are likely redundant, but I’ve left them in for completeness.

Windows Search 4.0 Administrator's Guide

Windows Search 4.0 has a number of new features and enhancements that can help IT professionals deploy and maintain desktop search:
  • Improvements in performance and stability of the indexer
  • Fuller complement of Group Policy settings, available on all supported operating systems
  • Fast sorting and grouping of results in Windows Explorer
  • Improvements in indexing online e-mail
  • Ability to index delegate mailboxes for online e-mail
  • Support for indexing encrypted documents of local file systems
  • Expanded ability to do fast remote queries of file shares, including on Windows XP and Server 2003
  • Automatic indexing of shared folders
  • Improvements in previews for earlier, supported operating systems (Windows Server 2003 and Windows XP)
Windows Search 4.0 extends the ability to search across remote desktops. Previously, only Windows Vista users could query recognizable indexes on remote Vista computers; now, WS4 enables users to query remote computers running any supported operating system. Remote querying includes the following features:
  • Queries work across all supported OSes (Windows XP, Server 2003, Home Server, and Vista).
  • All shared NTFS folders are automatically indexed (excludes all FAT file systems).
  • All shared, and therefore indexed, locations can be remotely queried.
The location on the remote computer must be shared and it must be indexed. With Group Policy, administrators can control whether shared locations are automatically indexed.
Querying from Windows Vista or Windows Server 2008
To query a remote computer, users use Windows Explorer to browse the shared, indexed folder on another machine and enter their searches in Explorer’s search box. If the location is not indexed, then Vista falls back to a slower GREP search instead of WS4.
Querying from Windows XP or Windows Server 2003
To query a remote computer, users select the location from their All Locations menu and enter their search query as usual. First, of course, they must add the remote location to their search scope:
  1. From the Windows Search UI, click the All Locations menu and select Add Location.
  2. Enter the full path of the location, or browse to the location.
Once added, the new location appears at the bottom of the All Locations menu allowing users to select that location to search in. In the same way, users can remove a location by selecting Remove Location. If the remote location is not indexed, a message appears advising users that the location cannot be searched.

FTP default domain setting


When using FTP in IIS on a Domain you must have to pain stakingly put the domain name in the username every time. Yes, this insures that the remote user must not guess just username, but domain name also. If this is of no concern to you there is a way to set the FTP default domain.
That is, if your domain is SeattleDom then, prior to editing, user John Doe must login with a user name of SeattleDom\JDoe.
Following the steps below will drop the domain requirement and allow a username of simply JDoe.
To set the default domain used for things like ftp go to the IIS server and:
Modify the DefaultLogonDomain in the IIS Metabase
When you specify the DefaultLogonDomain domain in your IIS settings, users are not required to enter their domain name with their user name (for example, MYDOMAIN\MyUserName) when logging in to your FTP site. If your FTP server is a member server, and the user accounts are in the local security database, this task is not necessary.
Click Start, and then click Run.
In the Open: text box, type cmd .
At the command prompt, type the following for your version of IIS:

For IIS 4.0, type:
cd /d %windir%\system32\inetsrv\adminsamples
cscript adsutil.vbs set msftpsvc/DefaultLogonDomain domain_name
For IIS 5.0, type:
cd /d %systemdrive%\inetpub\adminscripts
cscript adsutil.vbs set msftpsvc/DefaultLogonDomain domain_name
For domain_name, type the name of your domain.
Type exit to close the command prompt dialog box.
 
Blogger Wordpress Gadgets