Category Archives: VDI

License activation for Adobe CS6 in a View linked clone environment

Update 2018-08-02

I haven’t had to do this since I wrote this blog post in 2012. However, somebody found this post about a year ago and told me they were able to use Adobe’s current tooling with my old post to make it work for their Horizon environment. I just got a question today on this blog post.

The current tool is called Creative Cloud Packager. It’s not quite the same as Adobe Application Manager, but the concepts are similar.

https://helpx.adobe.com/enterprise/kb/edu-deployment.html
https://helpx.adobe.com/enterprise/package/help/creating-packages.html
https://helpx.adobe.com/enterprise/package/help/create-license-file.html

 

Original Post 2012-09-23

I recently had to work out the process for license activation of the Adobe CS6 suite. Adobe offers an academic FTE licensing scheme similar to Microsoft’s FTE program. The calculation for licensing cost is based on your employee count; the entire district is then licensed and you don’t pay a dime for students. The Adobe K-12 Enterprise Agreement contains Design/Web Premium, Photoshop Elements, Captivate, and Presenter.

The total installed size of these products turns out to be 8-10GB, quite a bit of a nightmare to attempt a ThinApp. I decided to bake the Adobe software directly into the base image. However, Adobe license keys do not survive the quickprep process. The software comes up unlicensed when you log in to a linked clone.

Adobe offers a free enterprise deployment tool called Adobe Application Manager. One of the functions is to create a serialized installer key along with an executable that will license the already-installed Adobe software. Note that this does NOT work on Photoshop Elements. We have a ticket in to Adobe support for assistance, but at the moment it doesn’t appear possible to activate Photoshop Elements anywhere other than during installation.

First, download and install Adobe Application Manager. Then download your Adobe software and unzip the installation files. Then launch Adobe Application Manager. I found that it only worked properly when I chose Run as Administrator.
Launch Adobe Application Manager
Select the Serialization File option from the main menu.
AAM Main Menu Selector
Browse to your unzipped installer, you need to point to the folder that contains Set-up.exe. Then enter a folder name to save the serialized output, and a location on the network to save the folder.
Path to Installer

Enter the serial number.
Enter Serial Number

The output of the tool will be an executable and XML configuration file.
Application Manager output

Now we need to make this script run after guest customization. We put a C:\scripts folder inside each template. Then create customize.cmd in C:\scripts. Customize.cmd is a generic batchfile that will be called by View after it performs guest customization. You can only call one batchfile, so you either need to put every command in the customize.cmd batchfile, or use customize.cmd to call other batchfiles.
The script looks like this:
Customize script

Put one copy of the AdobeSerialization.exe into C:\scripts\adobe. Then create a folder for each Adobe product that you installed. Inside each of those folders is the prov.xml output file. Create the adobe-commands.cmd file and write it to call the executable once for each xml config file.
The syntax to run the licensing is as follows: AdobeSerialization.exe –tool=VolumeSerialize –provfile=prov.xml
Adobe licensing commands

Configure your View pool to run the customization script after the linked clone is quickprepped.
View Post-sync script

Now the Adobe products will be fully activated anytime you recompose your linked clone pools.

View Composer bug

I am building 3 new ESXi hosts to add to an existing 3 host cluster. The cluster is supporting a View install. The backend SAN is a fibre channel VNX. I attached my ethernet and installed ESXi via kickstart. As always, I did not attach the HBAs to ensure no accidental overwrites of a VMFS datastore.

I joined my 3 new hosts to the cluster and ran Update Manager to get them patched and up to date. While that ran, I started looking at zoning the fibre switches. As I did that, a problem with the desktop image was reported to me. I fixed the image, took a snapshot, and went to recompose my test pool to validate that the fix worked. The recompose fails with “View Composer Fault: VMware.Sim.Fault.VcDatastoreInaccessibleFault”

Hmm. I checked all three existing hosts and they were able to see all datastores. A quick Google search turned up KB2001736. The article states “This issue occurs when one or more hosts in the cluster do not have access to a datastore required by the pool. You may also encounter this if one of the hosts is in maintenance mode.”

This article doesn’t seem to convey the seriousness of the problem. View composer will fail to recompose if ANY host in your cluster loses access to the storage. It doesn’t matter if the host is in maintenance mode or not. I performed several tests to validate and they were consistent – any host with all paths down causes Composer to bomb.

Evicting the offending host from the cluster is the only solution. While this isn’t a major problem for my brand new hosts, it is inconvenient. For an actual production host, it is quite annoying. If you have a failing HBA, you can’t recompose unless you evict the host. This causes you to lose all of your historic performance statistics. Again, not a showstopper – but it’s not a choice you should have to make. View Composer should ignore hosts in maintenance mode.

VDI for Education

There are countless arguments against deploying Virtual Desktop Infrastructure (VDI). Traditional desktops are cheap. VDI means you buy both a thin client and a rack of expensive servers and storage for your server room. You need a solid network backbone. You need substantial bandwidth for your remote sites. This all adds up to a significant capital expenditure.

Even in the face of these objections, VDI can be an attractive option for education. You need to go into it with the mindset that you’re not going to save capital expenses over a traditional desktop deployment. What you can achieve are substantial savings in operational expenses, major improvements in reliability and (typically) an increase in user satisfaction.

A few reasons why educational institutions should consider a VDI deployment:

  • With Microsoft’s Enrollment for Education and Software Assurance, schools have a simple, low-cost way to acquire the required Microsoft licenses. You pay a fixed cost based on the total number of full time employees you have. You count them once annually and you are covered for the entire year, even if you add staff. You can license Windows 7, Office, Windows Server, Exchange, Sharepoint, SCCM, Lync, and Forefront through the agreement. Your students are included at no charge. You read correctly – the district doesn’t pay one penny for student licensing. Every student is fully licensed to use the entire suite of Microsoft software that your staff is entitled to use.
  • Your computer magically follows you – at least that’s what it will feel like to your users. When you sit down at a thin client in the library, your profile loads and it feels like your own computer. Your preferences are all saved, your files are all there, your browser bookmarks are all available. When you move to the teacher lounge and log in, it’s the same. Classroom? Same. How about logging on to the desktop from the Internet? Still the same. This might be the number one feature that generates genuine excitement from your staff. Once they start getting used to having their profile follow them everywhere, they’ll never want to go back. Your users who travel from building to building are typically thrilled with this – no need to lug a laptop around.
  • Thin clients have no moving parts and no hard drive to fail. They don’t fail very often. If you do have to replace one, it’s a simple 5-10 minute process. No need to push a desktop image down, no need to reconfigure a user’s local profile or recover documents from their USB sticks. You won’t be performing hardware CPR for 2 days trying to resurrect a user’s machine. All you do is yank out the old thin client, install the new, and let the user log on. They see the same desktop that they saw before the hardware failure. If the user happens to have some critical task to complete before you can pull a spare thin client off your shelf, they can sit down at any thin client in the building and see their own desktop.
  • District IT staff doesn’t have to waste countless hours updating Macs. Macintosh computers are simply not geared for enterprise management. Think about running software updates on one Mac. Now run them on a whole lab full of Macs. Now run them on 10 labs full of Macs. Suddenly an entire work week is gone. With VDI, the process of manually updating each machine is eliminated. Instead, you update once and automatically deploy the updated image to your users. This, of course, assumes that you’re using a centralized image. VMware calls it linked clones, and Citrix calls it pooled desktops.
  • Everybody has the same version of installed software. There is no need to save your files down a version because the whole district has the same version of the Office suite. The benefits of this are difficult to quantify as it’s nearly impossible to calculate how much time people used to spend district-wide sending and resending documents due to compatibility problems. Your users will still be happy to never deal with that issue again.
  • Users aren’t going to like this at first, but if you use linked clones, it makes the IT department the gatekeeper for application installation. There is no way for users to install unauthorized applications. This can be both a blessing and a curse. On the plus side, users can’t sneak a garbage app into the environment. What will typically happen is a user gets grant money for some app, they install it themselves and then IT is stuck trying to band-aid it because it’s not a fit for the environment. With a linked clone environment, users quickly learn that they have to involve IT in the process before purchasing an application.
  • Users are typically blown away by the speed and responsiveness of the VDI desktops. It’s very common to go into an environment and see boot times of 5+ minutes, and logon times of 2-5 minutes. Replace that with a thin client boot time of 10 seconds and a logon time of 15-30 seconds and your users are overjoyed. A significant improvement in response time would be seen in any hardware refresh, virtual or not. However, pooling all of your CPUs, memory, and storage in the datacenter allows you to harness the computing power that would otherwise be sitting idle.
  • Electricity savings can be substantial. You would definitely have to take specific power readings in your environment before calculating ROI, but a desktop computer draws between 65-250 watts of power. A thin client such as the Wyse P20 draws 15 watts. If you multiply the savings by hundreds or thousands of workstations, you can get into some serious money. The savings is at least partially offset by the increase in power draw at your datacenter. In many cases, the cost savings is still significant.

Virtual desktop technology is mature enough to deploy into Production without concern. With a properly designed infrastructure, you can support your entire district and provide faster response and repair times to your users. If you’re looking for more information, my employer can help. Contact us and let us know what you’re looking for.