Updated Permission Set for View 4.x Composer Role


This did not come to my attention until I found a use case for ‘local mode’ vm’s.  The following table contains updated permission sets for View 4.x when using local mode and the new Transfer server.  This is an update to my previous entry.


Privilege Group Privilege(s) to Enable
Folder Create Folder 
Delete Folder
Datastore Browse Datastore 
Allocate Space 
Low Level file operations
Virtual Machine Inventory (All Rights) 
Configuration (All Rights) 
Interaction > Power On 
Interaction > Power Off 
Interaction > Suspend 
Interaction > Reset 
Provisioning > Clone VM
Provisioning > Clone Template
Provisioning > Allow Disk Access 
Provisioning > Deploy Template 
Provisioning > Read Customization Specifications
Resource Assign Virtual Machine to Resource Pool
Global Enable Methods 
Disable Methods 
System Tag

NOT in the install guide: 
Global Tag
Manage custom attribute
Network Install Guide says (all), but I’ve only ever needed the following:
Assign Network
Sessions NOT in the install guide: 
Validate session 
View and Stop sessions
Host In Configuration:
System management

System Center CodeName: Concero, a vCloud Director MS Version

Looks interesting especially that it also ties into Microsoft's Azure product as well.  Definitely something to be watching.  Will end up being a part of the System Center Suite License.  You can find more information here:

vCloud Info here

Hypothetical Cloud-Based ThinApp w/ View

The great thing about View is it’s simplicity.  Add into ThinApp, and you’ve got something awesome.  How do I setup ThinApp delivery and provide application level data persistence w/ geologically dispersed View hosted datacenters.  Easy.
  1. View 4.5+
  2. ThinApp 4.5+
  3. Some kind of DFS
  4. Some kind of NAS that does de-duplication.
  5. Active Directory
  1. Capture your ThinApp
    • Generate a MSI (streaming would be preferred)
    • Sandbox Location should point to your DFS share (which is hopefully on a deduplicated lun/nas)
      • Path should be something like this:
      • \\somedfsshare.local\%USERNAME%\
        • This will create a unique sandbox per user and persist their application information even on a non-persistent desktop.
    • Project Location is up to you, but I would generally also place this in a DFS share so updates can be replicated easily.
Once you’ve done this, you’ve essentially created a ‘cloud’ ready ThinApp that your VDI/View users can use no matter what View infrastructure (in your control) can access.  Hypothetically anyway, I'm still working out semantics.

ESXi 4.x and Dell OMSA

Read a write up from Alan Renouf on the subject.  Was pretty clear up until the point where it’s mentioned that you must use ‘Dell OpenManage Server Administrator Managed Node’ as a proxy to access a page that you would normally see on a Classic ESX box (https://esxserver:1311).  This is to clarify how that is exactly done.
  1. Install OMSA on a box, normally vCenter is physical, so that would be your best server.
  2. Install OMSA VIB on ESXi server.
  3. Go to your vCenter’s OMSA URL (https://vcenterserver:1311)
  4. Click on the link that says “Manage Remote Node” (Version 6.5 pictured below)
    • DellOMSA
  5. The screen changes and asks for the ‘remote’ system you want to connect to.
    • DellOMSARemote