Tuesday, December 6, 2011

Enable SSH on VMWare 5 ESXi

How to Enable SSH Access on VMWare vSphere 5 ESXi



Enabling SSH remote access to the console of an esxi 5.0 vmware host server is the same as in ESXi 4.1 (not 4.0 and earlier). In 5.0 vmware vSphere ESXi and 4.1 vmware vSphere ESXi it can be accomplished using the vSphere client. With earlier versions, like enabling SSH on ESXi 4.0, it had to be done via the server console.

Enable SSH on VMWare 5 ESXi

How to Enable SSH Access on VMWare 5 ESXi


Enable SSH for remote connections from the vSphere Client
perform the following short steps to enable access to the ESXi Shell using the vSphere Client:
- Logon to the up to date VSphere client
- Select from the list of hosts the ESXi host you want to configure and choose Configuration then -> Security profile
- From the Services section under Security Profile, select Properties
- Select the SSH option in Properties and choose Options
- Select Start to start SSH on the host.
- Repeat the process for each ESXi 5 host.

There is no global or farm-like setting that would allow you to do all your hosts at once. Perhaps that will come in the next version ESXi 6 .


Saturday, December 3, 2011

XenApp 6 HP Universal Drivers with Session Printers

XenApp 6 HP Universal Drivers with Session Printers

In a few words I can tell you that using HP Universal drivers with Xenapp 6 to create or add session printers to user's ICA session is not a good idea. The drivers corrupt very quickly. I was involved in a Citrix Xenapp 6 deployment, a small deployment, of six servers. The installation was fresh so there was no history to be brought into the mix and be factored in as a collateral cause. Xenapp was installed on 6 new virtual 2008 R2 servers (The virtual architecture was VMWare 4.1) . It was a new Citrix xenapp farm and the server 2008 R2 server had all the OS updates. The xenapp servers ha the following hotfixes:


The Citrix Online-Plugin was updated through the office to version 12 of the full plug-in. All desktops were XP. The goal was to add session printers through Citrix policies. What printers were added depended on the location the user was in. If they were in office location A they would get a certain number and type of printers. If they were in location B they would get another different set of printers and so on. The policy used the ip address of the client as the method to determine the location. That worked well. Session printer creation worked well in all tests before the app went live. Apparently, the one thing I can conclude is there was not enough load on the server to be an issue. Once the office had gone live with their published applications, within a week there very strange things happening. Printers that were not supposed to be part of the session were listed. Ghost or phantom printers that were in the session and did not belong could not even be printed to. The users would get access denied messages. The logs on the server were riddled with errors. Default printers were being set to these ghost or phantom printers and even when changed , they would just revert back. Then, there was no consistency either as to what "extra" printer would appear in the session at each login.
The problem was traced down to the HP Universal driver. Yes, it was the latest release from HP and yes all printers were on the supported printer list from Citrix.
The tool that was used to test the printer drivers was StressPrint. The driver was removed and re-installed. All seemed well for a few days and then the problem arose again. Of course this time the driver was removed and printer specific drivers were used.

Thursday, November 24, 2011

IP SLA Monitor Example for Fail-over Survivability of ISP

Configure ASA to allow traceroute responses


The following link is to an IP SLA configuration on a Cisco router that does not use the monitor command option:

Cisco ISP Failover IP SLA Configuration Example

IP SLA Monitor Example for Fail-over Survivability of ISP

Cisco IP SLA MONITOR example configuration. The IP address have been changed but this is a working configuration I just recently implemented. This office, actually and remote office with warehouse, has a T1 line they wanted a custom application to use exclusively but also had a DSL that was connected to a Cisco ASA 5505 (it could have been a Cisco 5510 or other). The ASA was also on the same LAN. The idea was simple, if the T1 fails, use the DSL for the custom application to connect to an online database source and server.

There are two tracker objects in a tracker list. The list uses a boolean AND,

track 10 rtr 20 reachability --> a ping to a target ip address for which there is ONLY a single static route to use the T1. This differs wit hthe IP SLA MONITOR vs. the IP SLA (with no MONITOR option available. Here, we had to use RTR instead of specifying the ip SLA number itself))
track 11 interface Serial0/1/0:0 line-protocol --> Interface status


track 20 list boolean and --> boolean AND, boolean AND means all conditions conditions have to be true , almost seems redundant but TAC did it this way on another remote office router.

object 10 --> tracker 10 shown above
object 11 --> tracker 11 shown above


ip route 4.2.2.2 255.255.255.255 192.168.1.11 track 20 --> tracked main route
ip route 4.2.2.2 255.255.255.255 192.168.1.1 100 --> alternate route is used if T1 is down

ip sla monitor 20 --> referenced in tracker 10

type echo protocol ipIcmpEcho 8.8.8.8 source-interface GigabitEthernet0/1 --> had to use the interface as source, using the ip address did not work (another bug, perhaps) , there is an explicit static route that says any traffic for 8.8.8.8 use the T1 (there are several ways to do this and you should test them on your router to be sure you can from the IOS command line ping and try all source interfaces before building this line. You can create the router using the next hop router for the T1 connection, or the route can be built by specifying the interface to source the ping from such as S0/1/0:0 on this router, or source the ping from the "inside" interface) So if there is a problem with the T1 the pings will time out.

timeout 1000 --> max ping reply time allowed in milliseconds
threshold 2
tag 20
frequency 5 --> status is checked every five seconds


ip sla monitor schedule 20 life forever start-time now --> scheduler for monitor 20


Cisco IP SLA Example for ISP failover