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.