Installing View agent on unmanged desktop source

When you need to install View agent on a physical box or an unmanged desktop source.  When you don’t control the VM infrastructure or maybe the VDI is in the cloud.  When you don’t have vCenter or license for vCenter managing the ESXi, one would argue that if you have license for VDI you have license for all the component to run VDI.  For my special use case, my View Connection Server is not going to be able to talk to the backend vSphere management Infrastructure for it is in a complete separate network.  In other words the virtual machine network and the vSphere network is physically separated and they don’t talk to each other.  There is one nic from each ESXi to the virtual machine network to expose the Win7 VMware View vm’s.  There would be zero attack footprint from the virtual machine network to the vSphere network infrastructure.  The only way to attack the vSphere infrastructure is through some kind of VMware tools to hypervisor vulnerability exposed on the VM itself that can attack the underlying hypervisor.  I don’t know of such vulnerability but it doesn’t mean there’s none and does not guarantee the future.  The possibility of such attack exist.  I don’t know what kind of sandboxing techinique VMware has for their vmtools for protection.  The other attack is, pretty obvious, if you are in the vSphere network itself, duh!!  Enough blablabla, this will take you to the GUI install and prompt you to supply the View Connection Server IP or FQDN.

VMware-viewagent-x86_65-5.3.-xxxxxx.exe /v”VDM_VC_MANAGED_AGENT=0″


View 5.1.2 Directory Traversal


I thought this was a relax Friday at the office today before CHRISTmas but I guess it is not.  After reading the reference patch from VMware advisory, I realize the urgency of the patch.  This is very important if you have a View Security Server expose from the outside network.  Without the patch you are asking for trouble so if you can’t patch it right away for whatever reason, you should shut down the Security Server or block users from reaching the Security Server until you patch the server.  Obviously if you have users using it applying the patch immediately is very important.  It is so important that you can’t wait for a nightly maintenance or if your boss is on CHRISTmas off and you can’t get permission.  This is an emergency patch.

You must also patch the View Connection Server VCS but this one is less risky than the Security Server (Still risky) since typically the VCS are only exposed internally.  This is true if your View infrastructure in designed with best practice in mind.  What do I mean, some View admins might use a full blown VCS and expose it to the internet for outside mobile users which is not the best practice.  If that is the case then you are at high risk and I hope you have your resume up-to-date and ready to go and if not, shut down your expose VCS first before you draft the latest one =).  Kidding aside, you should fix the architecture nondomain-joined View Security Server on the DMZ paired with the domain-joined VCS and apply the 5.1.2 patch.

The agent patch on the VM guest has no urgency so there is no need to apply the patch on each and every vm guest.  At least I did not see any urgency from the advisory.

I wish you all a blessed CHRISTmas!!