Version 4 of the Box Sync software purportedly resolves the sub folder sync issue and Box has deleted all incriminating support threads. I haven’t tested to ensure this is fixed, but they claim it is.

*Update 1/14/13* Due to a single and incredibly important feature gap in the Box offering, I have to recommend staying with Dropbox as of this writing. Incomprehensibly, Box does not currently support sub folder syncing via the desktop sync client, only top level folders. This means that any nested folders with content changes or creation will not be synced across your desktop clients. This also means that there is no selective/ targeted folder sync which is particularly useful for enterprise deployments who do not wish to sync GBs or TBs of top level data across hundreds or thousands of user desktops. I made the mistake, as did many others, that Box would support sub folder syncing, because, how could they not! Box reps message in a lengthy and frustrated customer support thread that this feature will be coming sometime in the first HALF of 2013, even though customers have been asking for this for over a year. Unacceptable and I'm not willing to wait. If and when Box finally gets their act together I'll reconsider their value proposition, but for now, I'm going back to Dropbox who have supported this feature since the days of beta. Box support thread. 

Box.com just got closer than ever to really competing head on with Dropbox for the free user. Box Sync, now available for free users, fills in a very large gap that previously prevented Box users from enjoying the full desktop to cloud experience. Box Sync provides the ability to sync your top-level only cloud-based files with a local directory structure on your PC, in a mostly similar the same manner as Dropbox. Box starts free users at 5GB vs Dropbox’s 2GB but if you are lucky enough to participate in one of Box’s numerous Android or IOS campaigns, you can grab a 50GB free account fairly easily. Dropbox rides on top of Amazon’s S3 service while Box runs its own infrastructure. There’s a lot to like about Box and now with Box Sync available, is it time to make a switch? Not until they fix their sub-folder sync issue, no.
I’ve been a loyal Dropbox user for a very long time now. Even though upload speeds can be temperamental, features are some what sparse, security has been a problem, and the service can be sketchy at times, it’s still a fantastic cloud storage platform that I use daily. Just like Dropbox, Box Sync requires a local install on your PC. Once installed, you will see the Box icon in your system tray, with a familiar right-click interface list of commands. The Box solution gives you many more options including a dedicated local recycle bin, the ability to force up or downloads, enable debug logging, as well as the ability to view and save the logs! Speaking as a professional technologist this is fantastic and much more in line with a true enterprise platform! 

The local client itself offers only a few options with most of the behind the scenes work happening online, as is the case with Dropbox.
You can rate limit up or download speeds and auto-sync everything. Also, unlike Dropbox, Box properly includes an auto-updating mechanism to keep Sync up to date. The lack of this feature in Dropbox really puzzles me.
Box also provides more granular sharing and security controls on the cloud side. Any folder or file anywhere in the hierarchy can be shared and customized for collaboration. Links can be left wide open, set to preview only with no download, or collaborators can be expressly invited and allowed. Passwords and link expiration are features available only in a paid plan.

You can also selectively sync any file or folder, initiate bulk uploads, plus a number of other things.

*Update 12/15/12*
Box just increased the file sizes for personal users to 250MB.

So far, Box looks great now! 50GB (if you’re clever), local to cloud sync, granular controls, enterprise-built platform…what’s missing? As it turns out, only file size limitations. Free accounts on Box are limited to 100MB 250MB per file and 10GB shared link bandwidth per month where Dropbox does not have these limitations.
Cheers, :-)
Box vs Dropbox

VDI is one of the most intensive workloads in the datacenter today and by nature uses every major component of the enterprise technology stack: networking, servers, virtualization, storage, load balancing. No stone is left unturned when it comes to enterprise VDI. Physical desktop management can also be an arduous task with large infrastructure requirements of its own. The sheer complexity of VDI drives a lot of interesting and feverish innovation in this space but also drives a general adoption reluctance for some who fear the shift too burdensome for their existing teams and datacenters. The value proposition Unidesk 2.0 brings to the table is a simplification of the virtual desktops themselves, simplified management of the brokers that support them, and comprehensive application management .

The Unidesk solution plugs seamlessly into a new or existing VDI environment and is comprised of the following key components:

• Management virtual appliance
• Master CachePoint
• Secondary CachePoints
• Installation Machine

 

Solution Architecture

At its core, Unidesk is a VDI management solution that does some very interesting things under the covers. Unidesk requires vSphere at the moment but can manage VMware View, Citrix XenDesktop, Dell Quest vWorkspace, or Microsoft RDS. You could even manage each type of environment from a single Unidesk management console if you had the need or proclivity. Unidesk is not a VDI broker in and of itself, so that piece of the puzzle is very much required in the overall architecture. The Unidesk solution works from the concept of layering, which is increasingly becoming a hotter topic as both Citrix and VMware add native layering technologies to their software stacks. I’ll touch on those later. Unidesk works by creating, maintaining, and compositing numerous layers to create VMs that can share common items like base OS and IT applications, while providing the ability to persist user data including user installed applications, if desired. Each layer is stored and maintained as a discrete VMDK and can be assigned to any VM created within the environment. Application or OS layers can be patched independently and refreshed to a user VM. Because of Unidesk’s layering technology, customers needing persistent desktops can take advantage of capacity savings over traditional methods of persistence. A persistent desktop in Unidesk consumes, on average, a similar disk footprint to what a non-persistent desktop would typically consume.

CachePoints (CP) are virtual appliances that are responsible for the heavy lifting in the layering process. Currently there are two distinct types of CachPoints: Master and Secondary. The Master CP is the first to be provisioned during the setup process and maintains the primary copy of all layers in the environment. Master CPs replicate the pertinent layers to Secondary CPs who have the task of actually combining layers to build the individual VMs, a process called Compositing. Due to the role played by each CP type, the Secondary CPs will need to live on the Compute hosts with the VMs they create. Local or Shared Tier 1 solution models can be supported here, but the Secondary CPs will need to be able to the “CachePoint and Layers” volume at a minimum.

The Management Appliance is another virtual machine that comes with the solution to manage the environment and individual components. This appliance provides a web interface used to manage the CPs, layers, images, as well as connections to the various VDI brokers you need to interface with. Using the Unidesk management console you can easily manage an entire VDI environment almost completely ignoring vCenter and the individual broker management GUIs. There are no additional infrastructure requirements for Unidesk specifically outside of what is required for the VDI broker solution itself.

Installation Machines are provided by Unidesk to capture application layers and make them available for assignment to any VM in the solution. This process is very simple and intuitive requiring only that a given application is installed within a regular VM. The management framework is then able to isolate the application and create it as an assignable layer (VMDK). Many of the problems traditionally experienced using other application virtualization methods are overcome here. OS and application layers can be updated independently and distributed to existing desktop VMs.

Here is an exploded and descriptive view of the overall solution architecture summarizing the points above:

Storage Architecture

The Unidesk solution is able to leverage three distinct storage tiers to house the key volumes: Boot Images, CachePoint and Layers, and Archive.

• Boot Images – Contains images having very small footprints and consist of a kernel and pagefile used for booting a VM. These images are stored as VMDKs, like all other layers, and can be easily recreated if need be. This tier does not require high performance disk.
• CachePoint and Layers – This tier stores all OS, application, and personalization layers. Of the three tiers, this one sees the most IO so if you have high performance disk available, use it with this tier.
• Archive – This tier is used for layer backup including personalization. Repairs and restored layers can be pulled from the archive and placed into the CachePoint and Layers volume for re-deployment, if need be. This tier does not require high performance disk.

The Master CP stores layers in the following folder structure, each layer organized and stored as a VMDK.

Installation and Configuration

New in Unidesk 2.x is the ability to execute a completely scripted installation. You’ll need to decide ahead of time what IPs and names you want to use for the Unidesk management components as these are defined during setup. This portion of the install is rather lengthy to it’s best to have things squared away before you begin. Once the environment variables are defined, the setup script takes over and builds the environment according to your design.

Once setup has finished, the Management appliance and Master CP will be ready, so you can log into the mgmt console to take the configuration further. Of the initial key activities to complete will be setting up an Active Directory junction point and connecting Unidesk to your VDI broker. Unidesk should already be talking to your vCenter server at this point.

Your broker mgmt server will need to have the Unidesk Integration Agent installed which you should find in the bundle downloaded with the install. This agent listens on TCP 390 and will connect the Unidesk management server to the broker. Once this agent is installed on the VMware View Connection Server or Citrix Desktop Delivery Controller, you can point the Unidesk management configuration at it. Once synchronized all pool information will be visible from the Unidesk console.

A very neat feature of Unidesk is that you can build many AD junction points from different forests if necessary. These junction points will allow Unidesk to interact with AD and provide the ability to create machine accounts within the domains.

Desktop VM and Application Management

Once Unidesk can talk to your vSphere and VDI environments, you can get started building OS layers which  will serve as your gold images for the desktops you create. A killer feature of the Unidesk solution is that you only need a single gold image per OS type even for numerous VDI brokers. Because the broker agents can be layered and deployed as needed, you can reuse a single image across disparate View and XenDesktop environments, for example. Setting up an OS layer simply points Unidesk at an existing gold image VM in vCenter and makes it consumable for subsequent provisioning. 

Once successfully created, you will see your OS layers available and marked as deployable.

 

Before you can install and deploy applications, you will need to deploy a Unidesk Installation Machine which is done quite simply from the System page. You should create an Installation Machine for each type of desktop OS in your environment.

Once the Installation Machine is ready, creating layers is easy. From the Layers page, simply select “Create Layer,” fill in the details, choose the OS layer you’ll be using along with the Installation machine and any prerequisite layers.

 

To finish the process, you’ll need to log into the Installation Machine, perform the install, then tell the Unidesk management console when you’re finished and the layer will be deployable to any VM.

Desktops can now be created as either persistent of non-persistent. You can deploy to already existing pools or if you need a new persistent pool created, Unidesk will take care of it. Choose the type of OS template to deploy (XP or Win7), select the connected broker to which you want to deploy the desktops, choose an existing pool or create a new one, and select the number of desktops to create.

Next select the CachePoint that will deploy the new desktops along with the network they need to connect to and the desktop type.

Select the OS layer that should be assigned to the new desktops.

Select the application layers you wish to assign to this desktop group. All your layers will be visible here.

Choose the virtual hardware, performance characteristics and backup frequency (Unidesk Archive) of the desktop group you are deploying.

Select an existing or create a new maintenance schedule that defines when layers can be updated within this desktop group.

Deploy the desktops.

Once the creation process is underway, the activity will be reflected under the Desktops page as well as in vCenter tasks. When completed all desktops will be visible and can be managed entirely from the Unidesk console.

Sample Architecture

Below are some possible designs that can be used to deploy Unidesk into a Local or Shared Tier 1 VDI solution model. For Local Tier 1, both the Compute and Management hosts will need access to shared storage, even though VDI sessions will be hosted locally on the Compute hosts. 1Gb PowerConnect or Force10 switches can be used in the Network layer for LAN and iSCSI. The Unidesk boot images should be stored locally on the Compute hosts along with the Secondary CachePoints that will host the sessions on that host. All of the typical VDI management components will still be hosted on the Mgmt layer hosts along with the additional Unidesk management components. Since the Mgmt hosts connect to and run their VMs from shared storage, all of the additional Unidesk volumes should be created on shared storage. Recoverability is achieved primarily in this model through use of the Unidesk Archive function. Any failed Compute host VDI session information can be recreated from the Archive on a surviving host.

Here is a view of the server network and storage architecture with some of the solution components broken out:

For Shared Tier 1 the layout is slightly different. The VDI sessions and “CachePoint and Layers” volumes must live together on Tier 1 storage while all other volumes can live on Tier 2. You could combine the two tiers for smaller deployments, perhaps, but your mileage will vary. Blades are also an option here, of course. All normal vSphere HA options apply here with the Unidesk Archive function bolstering the protection of the environment.

Unidesk vs. the Competition

Both Citrix and VMware have native solutions available for management, application virtualization, and persistence so you will have to decide if Unidesk if worth the price of admission. On the View side, if you buy a Premier license, you get ThinApp for applications, Composer for non-persistent linked clones, and soon the technology from VMware’s recent Wanova acquisition will be available. The native View persistence story isn’t great at the moment, but Wanova Mirage will change that when made available. Mirage will add a few layers to the mix including OS, apps, and persistent data but will not be as granular as the multi-layer Unidesk solution. The Wanova tech notwithstanding, you should be able to buy a cheaper/ lower level View license as with Unidesk you will need neither ThinApp nor Composer. Unidesk’s application layering is superior to ThinApp, with little in the way of applications that cannot be layered, and can provide persistent or non-persistent desktops with almost the same footprint on disk. Add to that the Unidesk single management pane for both applications and desktops, and there is a compelling value to be considered.

On the Citrix side, if you buy an Enterprise license, you get XenApp for application virtualization, Provisioning Services (PVS) and Personal vDisk (PVD) for persistence from the recent RingCube acquisition. With XenDesktop you can leverage Machine Creation Services (MCS) or PVS for either persistent or non-persistent desktops. MCS is deadly simple while PVS is incredibly powerful but an extraordinary pain to set up and configure. XenApp builds on top of Microsoft’s RDS infrastructure and requires additional components of its own such as SQL Server. PVD can be deployed with either catalog type, PVS or MCS, and adds a layer of persistence for user data and user installed applications. While PVD provides only a single layer, that may be more than suitable for any number of customers. The overall Citrix solution is time tested and works well although the underlying infrastructure requirements are numerous and expensive. XenApp offloads application execution from the XenDesktop sessions which will in turn drive greater overall host densities. Adding Unidesk to a Citrix stack again affords a customer to buy in at a lower licensing level, although Citrix is seemingly removing value for augmenting its software stack by including more at lower license levels. For instance, PVD and PVS are available at all licensing levels now. The big upsell now is for the inclusion of XenApp. Unidesk removes the need for MCS, PVS, PVD, and XenApp so you will have to ask yourself if the Unidesk approach is preferred to the Citrix method. The net result will certainly be less overall infrastructure required but net licensing costs may very well be a wash.

This architecture is a comprehensive update to a previous RA I wrote a few months back on RDS VDI using Server 2012. Below are the pertinent updated content sections of the document or you can pull from its published location on dell.com (August 2012): LINK

Summary

The Dell Windows Server 2012 RDS solution provides a robust and scalable VDI platform for pooled, personal and Session host deployments. Using VDI-optimized hardware in a configuration that has been validated and proven by Dell DVS Engineering, you can deploy Microsoft based VDI that is both cost effective and high performing. Our layered architecture provides flexibility to maximize your infrastructure investment with the capability to expand and contract where necessary.

New content:

• Single server 50 user/ POC offering
• Improved densities for both RDSH and RDVH session sources
• RDS options and Hyper-V architecture detail
• HA offering
• Updated test results and analysis

Local Tier 1 – Solution Layers

Only a single high performance Force10 S55 48-port switch is required to get started in the Network layer. This switch will host all solution traffic consisting of 1Gb iSCSI and LAN sources. Additional switches can be added and stacked as required to provide High Availability for the Network layer.

The Compute layer consists of the server resources responsible for hosting the user sessions, whether shared via RDSH (formerly Terminal Services) or pooled via RDVH (see section 4.5.1 for a detailed explanation of each role). The RDVH role requires Hyper-V as well as hardware assisted virtualization so must be installed into the parent partition of the Hyper-V instance. The RDSH role is enabled within dedicated VMs on the same or dedicated hosts in the Compute layer.

Management components are dedicated to their own layer so as to not negatively impact the user sessions running in the Compute layer. This physical separation of resources provides clean, linear, and predictable scaling without the need to reconfigure or move resources within the solution as you grow.The Management layer will host all the RDS VMs necessary to support the infrastructure as well as a file server to host SMB shares for user Profile Disks or data.

The Storage layer is made up by the capacity dense and performance capable Equallogic 4100E iSCSI array. 12TB is provided in base form that can scale as high as 36TB to suit your capacity requirements. A second 4100E can be added to group the two arrays to provided greater capacity or performance.

 

Local Tier 1 – 50 User/ Pilot

For a very small deployment or pilot effort to familiarize yourself with the solution architecture, we offer a 50 user/ pilot solution. This architecture is non-distributed with all VDI and Management functions on a single host. If additional scaling is desired, you can grow into a larger distributed architecture seamlessly with no loss on your initial investment.

Local Tier 1 – Combined

As a logical entry point to the distributed RDS solution stack, a combined architecture is offered to host both the RD Virtualization Host (RDVH) and RD Session Host (RDSH) roles within the same physical Compute host while separating the Management layer. This will enable users requiring either shared RDP or pooled VDI sessions to be hosted on the same physical server. The value of this solution is a minimum infrastructure investment with maximum VDI flexibility easily tailored to shared and pooled user types. Horizontal scaling is achieved simply by adding additional Compute hosts.

Local Tier 1 – Base

In the base distributed architecture the RDVH or RDSH roles are assigned to a dedicated Compute host. This architecture can support either a single RDVH or RDSH Compute host or one of each. This solution provides maximum Compute host user density for each broker model and allows clean linear upward scaling. You’ll notice that the hardware spec is slightly different for the two Compute host types, giving additional RAM to the virtualization host. This of course can be adjusted to suit your specific needs.

Fully Expanded

The fully expanded architecture provides linear upward scale for both the RDVH and RDSH roles optimized for 600 pooled VDI sessions or over 1000 shared. See Appendix for test results. This solution supports up to 4 Compute hosts of any combination running either RDVH or RDSH roles to meet the needs of the enterprise.

High Availability

High availability (HA) is currently offered to protect all layers of the solution architecture. An additional ToR switch is added to the Network layer and stacked to provide redundancy, additional Compute and Mgmt hosts are added to their respective layers, and Hyper-V clustering is introduced in the Management layer.

Solution Density Summary

Design Scale	Management Hosts	Compute Hosts	RDSH Sessions	OR		RDVH Sessions	HA
50 User / Pilot	0	1	100		50		-
Combined	1	1	130 + 75				+ 1 Compute +1 Mgmt
Base	1	1	260		145		+ 1 Compute +1 Mgmt
Expanded	1	2	520		290		+ 1 Compute +1 Mgmt
Fully Expanded	1	4	1040		600		+ 1 Compute +1 Mgmt

RDS Options

Server 2012 RDS provides a number of VDI options to meet your needs, all within a single, simple, wizard-driven environment that is easy to set up and manage.

• Sessions, hosted by the RDSH role (formerly Terminal Services), provide easy access to a densely shared session environment. Each RDP-based session shares the total available server resources with all other sessions logged in concurrently on the server. This is the most cost effective option and a great place to start with Server 2012 RDS. An RDS CAL is required for each user or device accessing this type environment.
• Pooled VMs are the non-persistent user desktop VMs traditionally associated with VDI. Each user VM is assigned a dedicated slice of the host server’s resources to guarantee the performance of each desktop. The desktop VM is dedicated to a single user while in use then returned to the pool at logoff or reboot and reset to a pristine gold image state for the next user. Applications can be built into gold images or published via RemoteApps. A VDA license is required for each non-PC device accessing this type of environment.
• Personal VMs are persistent 1-to-1 desktop VMs assigned to a specific entitled user. All changes made by Personal VM users will persist through logoffs and reboots making this a truly personalized computing experience. A VDA license is required for each non-PC device accessing this type of environment.

Compute Server Infrastructure

The Compute host configuration varies slightly as to whether it will be hosting RDSH or RDVH roles, or both. The RDVH role must be enabled in the Hyper-V parent partition thus providing one RDVH role per Compute host if pooled or personal VMs are required. The RDSH role should be enabled in up to 4 VMs on a single Compute host to support up to 260 session-based users.

The requirements for RDSH VMs are outlined below. All application and non-OS related files should be installed in the 5GB data disk:

 

Management Server Infrastructure

The Management host configuration consists of VMs running in Hyper-V child partitions with the pertinent RDS roles enabled. No RDS roles need to be enabled in the root partition for Management hosts.

Management role requirements for the base solution are summarized below. Data disks should be used for role-specific application files/ data, logs, IIS web files, etc and should exist in the Management volume on the 4100E array. Please note that the Tier2 volume presented to the file server is designated as a pass-through disk (PTD).

 

Solution High Availability

Each layer in the solution architecture can be individually protected to prevent an extended service outage. The Network layer only requires an additional switch configured in a stack with the first.

Protecting the Compute layer for RDSH and RDVH is provided by adding an additional host to a collection, thus effectively increasing the hosting capacity of a given collection. Session requests will be fulfilled by all hosts in the collection and as a result, each will have reserve capacity to insure against a host failure. Care needs to be taken to ensure that user provisioning does not exceed the overflow capacity provided by the additional node. A simple fail-safe measure would be to ensure that the appropriate number of users entitled to connect to the environment be tightly controlled via Active Directory. In a failure scenario users working on a failed host would simply reconnect to a fresh session on a surviving Compute host.

To implement HA for the Management layer, we will also add an additional host but will add a few more layers of redundancy. The following will protect each of the critical infrastructure components in the solution:

• The Management hosts will be configured in a Hyper-V cluster (Node and Disk Majority).
• The storage volume that hosts the Management VMs will be upgraded to a Cluster Shared Volume (CSV).
• SQL Server will be added to the environment to support RD Connection Broker HA.
• Optionally SQL mirroring can be configured to further protect SQL.
• The RD Connection Broker will be configured for HA.

Architecture Flow