Wednesday, 22 September 2010

Configuring SNMP on ESXi 4.1 via the vSphere CLI 4.1

1) Download the vSphere CLI 4.1 and install

2) From the VMware vSphere CLI command line, type:

vicfg-snmp.pl --server ESXIHOSTIP -c COMMUNITYNAME -p 161 -t DESTINATIONHOSTIP@161/COMMUNITYNAME

Example with output:

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin>vicfg-snmp.pl --server 172.16.4.101 -c anSNMPnm -p 161 -t 172.23.117.72@161/public


Enter username: root
Enter password:


Changing udp port to 161...
Complete.
Changing community list to: anSNMPnm...
Complete.
Changing notification(trap) targets list to: 172.23.117.72@161/public...
Complete.

3) Enable from the command line type:

vicfg-snmp.pl –server ESXIHOSTIP -E

Example with output:

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin>vicfg-snmp.pl --server 172.16.4.101 -E


Enter username: root
Enter password:


Enabling agent...
Complete.

4) Verify your settings, type:

vicfg-snmp.pl –server ESXIHOSTIP -s

Example with output:

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin>vicfg-snmp.pl --server 172.16.4.101 -s


Enter username: root
Enter password:


Current SNMP agent settings:
Enabled : 1
UDP port : 161
Communities :
anSNMPnm
Notification targets :
172.23.117.72@161/public

5) Test your settings, type:

vicfg-snmp.pl –server ESXIHOSTIP -T

Example with output:

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin>vicfg-snmp.pl --server 172.16.4.101 -T


Enter username: root
Enter password:


Sending test nofication(trap) to all configured targets...
Complete. Check with each target to see if trap was received.

Note: These settings are written to /etc/vmware/snmp.xml


Update - March 2011

Related post on how to monitor ESXi host hardware with HPSIM (this does not need SNMP enabled):
http://cosonok.blogspot.com/2011/03/monitoring-hp-vmware-esxi-hosts-with-hp.html

Friday, 10 September 2010

Citrix VDI Article 5/5) All XenDesktops have simultaneously shut down (system initiated guest OS shutdowns)!

By default, Citrix XenDesktops will shutdown 3 hours after losing contact to a Citrix Desktop Delivery Controller, if there is no resumption of communication. For this reason, here are a few recommendations:

1) Monitor the ‘Citrix Desktop Delivery Controller Service’ service

There is always a chance that this can terminate unexpectedly (as we have seen happen be it due to antivirus, software bug/glitch …)

2) Set the ‘Citrix Desktop Delivery Controller Service’ service to keep trying to restart

By default the service may be set to do ‘Take No Action’ on failure, set it to ‘Restart the Service’ on First, Second, and Subsequent failures.


3) Have two or more Citrix Desktop Delivery Controllers (all on exactly the same versions of Citrix and at the same patch level)

Citrix VDI Article 4/5) Getting the HDX File Access box to re-appear

Scenario: A user puts a tick in the box for ‘Do not ask me again for this virtual desktop’ and then wants to get the HDX File Access box back

Method 1/2
1) Right-click the 'Citrix Connection Center' icon in the notification area


2) Click on 'File Security'


3) And re-select as required


4) Click OK to close the ‘Citrix Connection Center’ box

Note: if there is no 'Citrix Connection Center' icon in your the notification area, or it appears and disappears quickly, update the client agent.

Method 2/2

1) When connected to your VDI, open up the 'Desktop Viewer Preferences' screen (click on the cogs icon)


2) On the HDX tab, adjust the 'File Access' settings to suit your preference



Citrix VDI Article 3/5) How to populate the domain box on the XenDesktop login screen

Walkthrough:

1) Connect onto the Citrix Desktop Delivery Controller
2) Open the Citrix Access Management Console
3) Expand ‘Citrix Resources’ -> Expand ‘Configuration tools’ -> Expand ‘Web Interface’
4) Click on ‘Internal Site’ and choose ‘Configure authentication methods’


5) With Explicit ticked, click on Properties…


6) Expand Explicit -> Click on ‘Authentication Type’ -> Click on Settings


7) Change the Domain list selection to ‘Pre-populated’ and add the domain into the box (by default the domain the CDDC is installed on is pre-added to the restricted domains list)


8) Click OK three times
9) (Optional) Repeat on the Citrix Secure Gateway server

Citrix VDI Article 2/5) Policy to stop local drives being available in XenDesktop

Why: for security or because users complain they see a lot of drives when they log into their XenDesktop

Walkthrough:

1) Connect onto the Citrix Desktop Delivery Controller
2) Open the Citrix Presentation Server Console
3) Expand the XenDesktop farm
4) Right-click on Policies and select ‘Create Policy’
5) Give the policy a name and description and click OK


6) Right-click on the policy in the contents pane and select Properties
7) Expand ‘Client Devices’ -> Resources -> Drives
8) Click on Connection and select Enabled and ‘Do Not Connect Client Drives at Logon’


9) Click OK
10) Right-click on the policy and select ‘Apply this policy to…’
11) Choose what to apply the policy to (in the example below, selected ‘Client Name’ -> ‘Filter based on client name’ -> ‘Apply to all client names’, to apply to all)


12) Click OK

Citrix VDI Article 1/5) How to disable session reliability on Citrix XenDesktop Farm

Problem: Remote office using Citrix XenDesktop through a VPN tunnel, reports bandwidth usage has increased dramatically due to traffic on port 2598 used by Citrix XTE Service / Citrix Session Reliability Protocol.
Solution: Disable session reliability on Citrix Farm

Side effects: Non reported

Walkthrough:

1) Connect onto the Citrix Desktop Delivery Controller
2) Open the Citrix Access Management Console
3) Expand ‘Citrix Resources’ -> Expand ‘Desktop Delivery Controller’
4) Click on the XenDesktop farm and from ‘Common Tasks’ choose ‘Modify farm properties’


5) Click on ‘Modify All Properties’
6) Expand ‘Farm-wide’ -> Select ‘Session Reliability’ -> Untick ‘Allow users to view sessions during broken connections’


7) Click ‘OK’

Thursday, 2 September 2010

Getting loads (thousands per second) of event 5145 for Detailed File Share on a Windows 2008 R2 File Server

On a recently built Windows 2008 R2 File Server, it was noticed that in the security log there were over 10000+ per second event 5145s for category 'Detailed File Share.'


Investigation into this pointed to an 'Advanced Audit Policy Configuration' item that is only available with Windows 2008 R2 and Windows 7; which is the subcategory item 'Audit Detailed File Share', and interestingly this was not configured.


It appears that if you have a domain or local policy that enables the normal 'Local Policies' → 'Audit Policy' for 'Audit object access' with Success and/or Failure


it causes the 'Audit Detailed File Share' to be configured unless you explicitly configure it with Success and/or Failure unticked.

After configuring the Local Security Policy on the file server with Success unticked (see below,) the number of security audit events recorded was drastically cut down, noticably reducing the CPU processing load.


Note: There is no granularity to this setting; it is either enabled or not across all the shares on the server.