VMware View, formerly VDI, is all about desktop virtualization, at the enterprise level. View integrates with and requires vSphere and vCenter on the back-end; Set up and configuration of these components is beyond the scope of this article.  The value proposition for View is heightened security and availability for desktops by moving them into the datacenter while reducing support costs due to centralized desktop image management. View can be used to provide and control access to VMs, terminal servers, or physical PCs and supports native MS RDP as well as PCoIP for an “optimized PC experience.” View services can be accessed via View, RDP or Thin client using several different display protocols.

The desktop in the datacenter proposition is an interesting one. If using persistent VMs then you can take advantage of the recomposition feature in View and dynamically update your parent image which will trickle down to all cloned VMs. Your desktops will also enjoy HA if hosted on an ESX cluster bringing a level of redundancy otherwise not possible with traditional PC hardware. Of course you will still need to procure and deploy thin clients on user desks that will consume an image in your View environment. Another benefit of this model is that desktops will follow users so no matter where they log in they will see their assigned desktop.

My use case is a little different. I have another stubborn app that (still) requires Office 2003 which has been long gone from my desktop builds for many years now. The terminal server solution works fine for this app but then we have a resource problem as particular functions of the app like to consume 100% of available CPU, starving the other connected users. For this particular case View is a great solution because I can deploy a desktop to each application user and guarantee a predictable performance level for each VM, eliminating contention. Through the View Connection Server I can broker client requests and direct my users to a single pool that will present their work spaces to them dynamically. In this project I will be integrating View into my production ESX cluster to provide 10 dynamic desktops to users of a business application.

View can be licensed in two flavors, Enterprise or Premier, VMware’s new scheme, and for new or existing vSphere customers. The key difference between the two is Premier comes with View Composer, Offline Desktop (experimental), and ThinApp. View Composer is required if you want to use the linked clone feature. Linked clones are spawned from a parent but are a fraction of the size (10MB) and point back to the parent. List prices range between $50 and $250/ concurrent desktop. Read more about the version differences here: VMware View.

Architecture

The required components of this solution are:

• ESX
• vCenter running View Composer
• View Connection Server (VM)
• Active Directory

The View Connection Server (VCS) will host the broker service that will direct clients to their presented desktops. VMware plainly states that this server role should not be installed on your vCenter server and must run on Server 2003 (R2) only, Server 2008 is completely unsupported at this point. VCS is fully supported as a VM in the cluster so no worries there. VCS can scale to support additional replica servers for large environments and security servers for DMZ deployments . A single VCS instance can support 2000 simultaneous connections (direct, RDP). VMware documentation can help you calculate overhead for varying workloads running on various desktop operating systems.

Here is my architecture as it will be implemented (terminal servers and PC are evolutionary considerations):

View Composer

While spinning up my VCS VM, I installed View Composer on my vCenter server. Although technically not supported, I was able to successfully install Composer on Server 2008 R2 with SQL Server 2008. First create a new SQL database for Composer where your vCenter database lives, View will use Windows authentication mode.  The key to getting through the installation is to set up the ODBC via the applet in the administrative tools folder (%windir%\system32\odbcad32.exe), not via the Composer setup wizard which will open C:\Windows\SysWOW64\odbcad32.exe.  Setup will only find a DSN configured with the administrative tools applet. If you use the applet called by the setup wizard you will get this error:

The rest of setup is straight forward and will result in the VMware View Composer service being installed and started. That’s it. There is nothing else to configure for Composer.

View Connection Server

Once the 2003 R2 VM is ready install VCS. VCS can be installed in one of 3 roles, for my purposes Standard is fine. Setup will also install an instance of MS ADAM to store View configuration data. After the first server is setup, if you need you can install replicas. The VCS will also run an instance of TomCat to host the View Manager website.

Parent VM

Before we configure View Manager, let’s get the parent VM ready. In vCenter create a regular VM with the desktop OS of your choosing, I’ll be using XP Pro SP3. Install all patches, needed software, antivirus, ODBC settings, and join it to the domain. Don’t forget to install the View agent as well and disconnect any floppies or CD-ROMs! Once everything is configured correctly take a snapshot in vCenter as this is what will allow the VM to be a parent in the View environment. This snapshot provides the baseline for the parent image.

View Manager

View Manager is the administrative tool used to configure View settings, accessed via a web browser. The site is accessed by connecting to your VCS server: https://VCS/admin. This is where you input your licensing information for your View environment which should be done first. Click Configuration, then Edit License under the Product Licensing and Usage heading. Next associate your vCenter server. You will need a domain service account that has administrative rights on both vCenter and VCS servers, as well as the ability to create and delete computer objects in the OU of your choosing in AD. This service account will be used to dynamically create VMs, join them to the domain, and then delete both when not in use. It does not need domain admin rights if properly delegated.

Add any users or groups that you would like to allow administrative access to View Manager. At this point we should now be ready to set up a desktop pool and start testing View. Click Desktops and Pools, then Add… to start the setup dialog.

There are 4 different pool types you can set up depending on your requirements, I’ll be setting up an automated desktop pool.

Desktop persistence will determine a few different features available to you after the pool is created. Persistent is suited for permanent user desktops and can be used with the parent VM recomposition feature while non-persistent will be temporary and cannot be used with recomposition. My View desktops will be used dynamically to run a specific application, not as permanent desktops so I will use non-persistent.

Along with non-persistent desktops I want to use the linked clone technology which will create clones of my parent VM that are a fraction of the size of the parent, 10MB per VM. This is very cool technology and huge disk space saver.

Configure a unique ID/ display name then move on to desktop/pool settings. Configure the desired behavior for each setting. I want to force the RDP protocol and destroy the linked clones when a user logs out.

Provisioning settings will determine the automated behavior of your desktop pool. I am licensed for 10 desktops but would only like 1 available at all times since they will not be used daily. As soon as a user logs into one another will start spinning up automatically .

Next select the parent VM you created and snapped earlier. Remember that only VMs with snapshots will be displayed here.

Once the parent VM has been selected you will see the snapshots attached to it. Select the appropriate snap and click next.

Setup will next create a folder in the location of your choosing to house the View VMs. It will name the folder based on the Unique ID you created earlier. Choose your host or cluster then select a resource pool and datastore. I’m not currently running DRS so I can’t create a resource pool in my cluster and am stuck using the default pool. Next move on to QuickPrep. This is where the integration magic is set up. If you set up your service account as I described earlier you will see it here in the dropdown. In the AD container box, enter the AD DN of where these VMs will live in your directory (in reverse order). Make sure to leave off the domain designations or setup will fail! (DC=domain,DC=com).

Review the settings on the next screen then click Finish to commit. You can now safely turn off your parent VM. Next you need to grant access to the users you want to be able to use the View desktops, this is done via the Entitlements… link.

Depending on your provisioning settings, you should now see at least the first desktop being created in vCenter. First View will create a replica source of your parent VM. This copy process will take a few minutes. Browse your datastore to see the new replica folder and files.

Once the replica is in place, linked clones will spin up much faster since they will point back to the replica source. Linked clones will continue to increase in size over time so it is a good idea to refresh them occasionally to reset their space consumption. When first created the linked clones are extremely small.

The View client should now be installed and users can log into the environment.

Although recomposition-on-the-fly is not available for non-persistent VMs you can still refresh your parent VMs, albeit a much more manual process which requires down time.

1. Destroy all desktop sources in the pool via View Manager
2. Disable the pool and new VM provisioning
3. Delete the snapshot on the desktop pool’s parent VM in vCenter
4. Make your changes and shut down the VM
5. Take a new snapshot
6. Edit the desktop pool in View Manager to point at the new snapshot
7. Re-enable the desktop pool and VM provisioning

Please note that by deleting the last clone in the pool will also trigger a delete of the replica. So when you enable the pool again the replica will have to be created again.

As of this writing only build 4.0.1-233023 is publicly available on VMware’s website. I was having a problem with provisioning where after a VM was spun up, View Manager would flag an error status and spin up another, even though the original was fine and fully usable. “View Composer agent initialization state error (6).

VMware’s posted solution to this problem is to create a batch script that reboots the VM again after the provisioning process has completed. This did not resolve the issue for me so I opened a case with VMware. They directed me to the bits for build 269620 which has resolved the issue! The download link I was given is public so I’m going to assume it’s ok to post here, see the references section at the bottom.

Client deployment can be easily accomplished using KBox, SCCM, or other deployment solution. Here is the command string I used to deploy in my environment (change the server name):

VMware-viewclient-4.0.1-269620.exe /s/v/qn DESKTOP_SHORTCUT=0 VDM_SERVER=<ServerName> REBOOT=Reallysupress

Conclusion

I am extremely impressed with VMware View and the lengths VMware has gone to, to ensure seamless integration into an existing enterprise environment. AD-integration is seamless as is desktop provisioning. I should not have to touch my View environment unless the parent VM needs to be updated. It is, however, additional infrastructure in what seems to be an endlessly expanding datacenter service footprint but the value and rewards are solid. If you already own or are planning to purchase vSphere and need a virtual desktop solution I strongly recommend you consider View 4.

References:

VMware View 4.0.1-269620

View 4 Architecture Guide

View 4 Deployment Guide

View 4 Admin Guide

In my previous anti-virus review for SEP11, I briefly touched on NOD32 and its underground fame among some IT enthusiasts on the web. Because NOD32 is an impressive personal scanner, I wanted to seriously consider ESET’s enterprise offering and possibly dethrone Symantec as my favorite enterprise AV solution. Through the use of numerous daily virus definition updates and a very aggressive heuristic scanning engine, NOD32 has managed to stay on top of the VB100 list by not missing any threats since 2002.

There are 3 installation components to the enterprise NOD offering: The NOD client, the ESET Remote Administrator Server (ERAS), and the admin console (ERAC). All 3 parts should be installed on the server to manage the environment, the console can be installed on an admin workstation for remote management. Component versions as tested are 4.x upgraded from 3. Licensing is per installed client enforced via a license file and ESET requires a username and password to pull virus definition updates from their servers. The client comes in both x86 and x64 flavors while the management components are x86 only. I had no trouble at all installing all components on Server 2008 R2.

When first launching the ERAC, it connects to the configured server on tcp/2223, by default, and asks for login credentials which can be optionally cached by the administrator.

At first glance the layout seems daunting.

The console can be customized in number of ways including column, color, and highlighting options for almost every piece of the layout. (Tools—>Console Options)

The next logical step is to configure virus definition updates and the other applicable global options. Under Tools—> Server Options, a number of things can be configured including passwords and access management for the ERAC, logging and DB maintenance, the update username/password and update interval, along with SMTP and optional upstream NOD server replication. As is the case with any enterprise technology, RTFM, but I really disliked the update setup requirements. The mandate of a username and password just to pull definitions is annoying and the “update mirror” setup used for definition storage is hardly intuitive. The mirror settings should come pre-defined in a base installation allowing further refinements if needed.

The performance statistics displayed on the General tab in Server Options is a nice touch albeit a bit out of place in a global configuration dialog.

Notification options seem robust and plentiful, at first glance. A number of pre-defined notification rules can be tweaked with HAS, HAS NOT, and IS types of filter parameters along with a number of wildcard fields that you can expose. Some of the default descriptions include wording that leaves much to be desired like “Primary clients with a non-cleaned infiltration during the last computer scan” instead of a much simpler “New threat detected.” Notifications also fall short in information richness. You can be notified that a “non-cleaned infiltration” was detected but you will have to log into the ERAC to find out exactly what that infiltration was. You cannot have the name of the detected threat included in the notification email.

We experienced a great deal of frustration surrounding alerting with this product. Server based alerting was slow and unpredictable at best leaving us to configure policies that enabled clients to send administrators SMTP alerts directly so we at least knew what was going on. Not good.

Policy management, again, seems very rich and robust, at first glance. NOD employs the traditional parent/child inheritance model making it easy to create and deploy child policies to specific machine categories such as department or function. Each policy can be edited/viewed individually or in a merged state to display the effect of parent policies.

Configuring policies themselves can be a daunting task with hundreds of stacked options available to you. While I would normally find this level of control of positive thing, it’s implementation here is very user UNfriendly. Although the search feature works fine here, trying to pinpoint and enable or disable a very specific behavior can be very challenging [and frustrating].

Another problematic behavior of this policy model is that it follows an append behavior by default. So any policy changes you make will simply be tacked on to the client’s existing policy, not changed or deleted. First level ESET support told us this was by design (bad) although level3 ESET support tells me there is a way to flag a policy item as delete so the client will remove it. Going back through the dialogs now I don’t see that option anywhere. If it exists it should have been made plainly clear in the Policy Manager console. Scanning profiles are used to control on-demand scans and configured via policies then deployed to clients. We had a hard time making these profiles “stick” after any policy change. We kept wondering why clients weren't running their weekly full scans, it was because the scanning profile dropped and the weekly's never kicked off!

The level of configurable policy detail is immense, but most notably lacking is the ability to modify a client’s Scheduler/Planner settings, namely startup scans. By default the NOD32 client will initiate a scan each time a user logs in (even workstation unlocks) and when the virus definitions are updated. The logic behind this is understandable which is to ensure maximum protection, but it comes at a hefty, and annoying, performance penalty. Add in the complete inability to centrally control and you have a very large annoyance. Tasks can be added to the Scheduler/Planner via Policy Manager but not deleted.

ThreatSense is the heuristic scanning engine that makes the product look good in virus tests and marketing materials but those of us in the trenches know good and well that this is a slippery slope. I always disable heuristic scanners because they are too difficult to control and often block perfectly legitimate applications from operating properly. ThreatSense is no exception. In our tests it seemed to haphazardly block legitimate operations even after allowing them to run a few times before, such as application deployment via our KBox. So much so that we started looking to NOD first when any application wasn’t functioning correctly. Settings for ThreatSense are controlled outside of the normal real-time AV rules. My advice, disable ThreatSense during the installation just like you would in any other AV product, the headache is not worth it!

Scheduled scans are also configured in policies (buried under ESET Kernel\Scheduler/Planner) but we found the execution to be sometimes unpredictable. Instead of firing at the specified times, these scans seemed to kick off when they wanted to even though they were expressly set.

Remote client installation from the server works well enough but clients reporting into the ERAC is somewhat unpredictable. The display is only updated periodically so it is hard to tell if a client is really out of date or disconnected just from looking at the console. Requests to update individual clients from the ERAC also seem to go by unanswered.

Other pain points include the lack of fine-tuned resource throttling for scans actively running on machines with other workloads. The NOD client will simply take as much of the CPU as it wants to even though the scanning profile is set to run background scans with low priority. All you can do is to stop the scan, which in and of itself is sometimes difficult to do. ESET touts it’s low resource utilization which may be true for real-time AV protection but I beg to differ on full scanning operations.

There is a lot to like with the NOD client itself, however. It is clean, un-intimidating, and tells you exactly what you need to know. It will even turn red in the system tray to warn you when new Windows updates are detected, overkill yes but it wants you to be secure.

The full advanced configuration dialog is accessible via the client in a much more condensed, clean and user-friendly form. It is very clear that ESET has spent a great deal of time and effort developing their client.

Working with this product for awhile now it is clear that ESET built a very good AV client then bolted an attempted enterprise management piece on top of it (ESET support confirmed this). In version 4 of the enterprise platform I expected much more, especially after upgrading from version 3. While clunky and very unrefined in spots, if you have the time to mess with it, this solution should work for very small environments, even though you will spend much more time here configuring and tweaking.

There are a few key points that make the enterprise solution a complete deal-breaker for me in its current state. Notification options/behavior, predictable manageability, and policy behavior are bad enough, in my opinion, that I cannot recommend the product. In my conversation with ESET’s level 3 support, he acknowledged many of my concerns and remarked that the development group that works on the enterprise piece is not exactly steeped in what a real enterprise requires, being a very small dev shop themselves. Would I run NOD32 at home? Sure, but that is where my recommendation ends. For your SMB+ sized enterprise you would be much better served implementing a tried and true solution built for the enterprise market.