Workspace One screenshots

Posted on February 9, 2016 by pkremer

Today, VMware announced the launch of Workspace One and I wanted to throw a couple of screenshots out there. As a field engineer, I use Horizon Workspace every day to access my work applications. I’ve been using Workspace One for the last month and I’m happy with how responsive it is.

This is the Android URL to get the Workspace One App on your phone:
https://play.google.com/store/apps/details?id=com.airwatch.vmworkspace&hl=en

And the Apple AppStore:
https://itunes.apple.com/us/app/vmware-workspace-one/id1031603080?mt=8

This is what my workspace looks like in Google Chrome. I’ve got the Favorites showing, which are the 6 primary apps I use at VMware. Our catalog is full of many dozens of apps, it’s nice to have a quick Favorites list.

This is the Workspace One app on my iPhone. It’s an almost identical look and feel, and the favorites I set while in Chrome are the same favorites on my iPhone.

At VMware, we use two factor authentication to access Workspace One. However, I only had to enter my credentials with RSA key once. After that, I can go back into the app with my Touch ID stored on the iPhone.

VMware View Composer starts, but does no work.

Posted on January 7, 2013 by pkremer

I worked on a client outage over the weekend, Virutal Center and View Composer were down. It started with a disk full situation on the SQL server hosting the vCenter, Composer, and Events databases. The client was shut down for winter break, so the Composer outage was not noticed for several days. After fixing the SQL Server disk space problem, everything came back up. I was able to restart all services and they appeared to be running. Composer started without issue, but it didn’t respond to any commands – any operations I requested in View Manager were ignored. I didn’t find any obvious errors in the logs.

I ran through the troubleshooting options in KB1030698 without finding any issues. I validated the SDK was responding by going to https://vcenteripaddress/sdk/vimService.wsdl . I couldn’t find any cause for the outage, so I opened up a Sev-1 ticket with VMware Support.

The support tech concluded that a problem with the ADAM database was preventing Composer from doing the job. He had me shut down all but one connection broker, then restart the View services on the remaining broker. At this point, commands issued on the broker were obeyed by Composer. We deleted or refreshed all of the desktops listed under Problem Desktops. Once we were sure that the ADAM database reflected the true state of the environment as reflected in vCenter, we restarted the other brokers. They synced databases and the problem was resolved.

License activation for Adobe CS6 in a View linked clone environment

Posted on September 23, 2012 by pkremer

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.

Select the Serialization File option from the main menu.

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.

Enter the serial number.

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

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:

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

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

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

VMware View / PCoIP / PowerPoint bug

Posted on August 18, 2012 by pkremer

We just went live with a 400-seat View deployment at a school district. They have Wyse P20 zero clients which have dual DVI monitor ports. The project was a complete rip-and-replace – routers, switches, wiring, all Mac computers replaced with P20s, and two new racks full of gear in the server closet.

The teachers arrived this past week and started working on transferring their files off the Macs. One of them brought a problem to my attention – when he was trying to run his PowerPoint in presenter mode, the projector showed nothing but a black screen. Interestingly enough, if he used the marker tool to draw on his side of the presentation, the slide on the projector suddenly appeared.

Slideshow ribbon in Powerpoint 2010

A Google search for the View release notes turned up with this, listed as a known issue in every View release since 4.5:

In Windows 7 desktops when connected using PCoIP in multiple-monitor display mode, if you choose Show On: Monitor Generic Non-PnP Monitor for any monitor other than the primary monitor in PowerPoint 2010, a black screen is displayed instead of a slide show.

Workaround: If you are using PowerPoint 2010 in a Windows 7 desktop, you must use Show On: Primary Monitor for a slide show.

One immediate workaround that other engineers at my company suggested is to use the RDP protocol. This does work, the issue does not exist when using RDP. However, it wasn’t an option at this client as the user endpoints were PCoIP Zero clients.

This was a huge problem for user acceptance of the project. Most of the teachers were used to presenter mode for delivery of their slideshows. The only workaround was to connect the projector directly to DVI output #1 and have the teacher present directly from the projector. Many teacher desks were oriented such that the teacher couldn’t even see the projection – either we got the presenter mode to work or we were asking dozens of teachers to rotate their entire classroom one day before students arrived. It wasn’t really a good workaround for teachers who could see the projection anyway. This district uses hosted PowerSchool for their student information system. They take attendance online and you generally wouldn’t want to project the process of logging into the system. A teacher could easily reveal credentials and allow students to log in and change grades. So we were down to having to switch video cables from the projector back to your monitor many times a day – a bit frustrating to say the least. We discussed a DVI splitter but that wasn’t a great option either, it would be a little easier to disconnect the projector when you didn’t want to project, but it was still kludgy.

I opened up support tickets with VMware and Teradici at 7:30 PM. The client paid for 9×5 support, so I wasn’t going to get an answer from VMware for quite some time. Teradici was a different story. They are the creators of the PCoIP protocol and maintain firmware and management software for zero clients. You can log on to http://www.teradici.com and get support if you’re running a PCoIP solution.

I went home and woke up to discover that e-mails from Teradici support had arrived in my inbox at 7:30AM. The support tech had already tested the bug out in his lab and had a way to resolve the issue. That’s a completely free 12-hour turnaround with resolution!

The fix was to enable 3D rendering. First you enable it in the pool. Doing so means you can no longer support RDP connections to the pool, so you have to turn off “Allow users to choose protocol.” Then enable 3D Rendering.

Enabling 3D rendering in View

Next, enable 3D support on your template VM. For me, Performance was unacceptable with less than 64MB of video RAM, and it got better with more. You might want to experiment with various RAM settings to determine the best setting in your environment.

Enabling 3D support on a VM

Then inside your template, enable Aero. The quickest way I found is to search for aero, then click “Find and fix problems with transparency and other visual effects.”

Enabling Aero in Windows 7

Enabling Aero turns on the “pretty” features of Windows 7, which suck up memory and CPU cycles. I found the VM to be sluggish with Aero enabled, so I set the VM’s visual effects to Best Performance.

Adjusting Windows for Best Performance

I recomposed my pool, tested it out, and it worked! There is definitely a penalty here in the form of increased resource use, but it gets the technology out of the way and lets the teachers focus on teaching the lesson.

Many thanks to the folks over at Teradici for this fix!

View Composer bug

Posted on June 27, 2012 by pkremer

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.

Configuring View security servers

Posted on May 31, 2012 by pkremer

I recently spent a very long time troubleshooting a View security server, documented in this post. As part of my sanity checking, I checked and rechecked all of the necessary settings for a security server paired up with a connection server. I didn’t find any helpfile or blog post that clearly spelled out what I needed to have configured, so I’m putting up a quick post.

This is the View connection broker that’s paired with the security server. The external URL and the PCoIP external URL are the private IPs of the connection broker itself. The security server in the DMZ must have access to these IPs. I won’t rewrite the firewall rules required, but check out KB1027217 for a detailed list of ports. The IP here is the IP that the security server sees for the connection broker. If you’re doing some kind of NAT from your DMZ to the inside, you’re going to have to key in the IP address on the DMZ side of the NAT.

This is the paired security server. Here we use public IP addresses. This IP must be NATed externally to the private IP of your security server… unless of course you use public IP addressing inside your DMZ (yikes).

It’s not easy to test your changes externally. You could work remotely with multiple computers, one on the VPN to make your configuration changes and another testing connectivity from the public internet. That’s not always a feasible option for a consultant. You will typically not have a good way to test externally while inside the client’s network. I do a lot of work in education and many schools are built like bunkers – no cellular signal at all, so a MiFi or tethering is out as well. One easy way to test communication from the DMZ to the inside is to put a temporary VM in your DMZ segment. Give it an IP in the same subnet as your security server, and install the View client. In View, configure the security server to use the private DMZ IP instead of the public IP for the external URL and the PCoIP external URL. You can then test from your temporary VM. Once you get it working, change the external URL and the PCoIP external URL back to the public IP. Then you can get the external NAT and external firewall rules working – this is not a complex configuration and won’t require much trial and error.

Check the path – A lesson in PCoIP troubleshooting

Posted on May 30, 2012 by pkremer

I’ll start with the moral of the story – when you’re having network issues, check the entire path.

I had an ongoing issue on a client’s network involving VMware View 5 and PCoIP. All internal traffic worked fine. Any PCoIP traffic that passed through the Cisco ASA firewall timed out. I could not get PCoIP traffic to work externally through the DMZ. It was the same behavior you get when the firewall has blocked ports. However, the firewall rules all seemed to be correct. When I switched the View client to use RDP, it connected to the desktop.

I opened a ticket with VMware support. They performed a bunch of troubleshooting, including running custom utilities to validate that all firewall ports were open. Everything checked out, and they blamed the Cisco ASA. I found a View-related bugfix on the Cisco website and tried flashing the ASA, but the problem persisted. So I opened up a ticket with Cisco TAC. They did their troubleshooting including packet captures and found nothing wrong. Their analysis was that the internal View connection broker was sending a FIN message to terminate the PCoIP session.

Back I went to VMware support, and they again failed to come up with a solution. So I was sitting there one day and my eyes floated over to the network diagram hanging on the wall. BAM. The cause of the problem was staring me right in the face. The customer has a Cymphonix web filter device, it functions as a bridge between the Cisco ASA and the internal network core. I tried digging through the logs on the Cymphonix but found no evidence of any packets being dropped. I put in a call to Cymphonix support anyway. I discovered that the Cymphonix was definitely dropping the PCoIP packets.

I had run afoul of a feature called Anonymous Proxy Guard. It’s designed to prevent a user from bypassing the Cymphonix by using another proxy server. The feature detects the PCoIP protocol as an anonymous proxy and drops the packets. Cymphonix support couldn’t give me a satisfactory explanation for why the device didn’t/couldn’t log the drops. I reconfigured the Cymphonix to stop using Anonymous Proxy Guard for all traffic inbound and outbound from the View Security servers. Problem solved.

The next time you’re having a problem like this, trace the entire network path!

View 5 Personas with Forefront Endpoint Protection

Posted on February 15, 2012 by pkremer

Update 2/15/2012
I now have my very own VMware KB article documenting this issue – KB2011823

Update 1/20/2012
I have been trying to find a resolution to this for several weeks, scroll down for a full description of the performance problem that FEP causes with View 5 persona management. The issue found its way to the the View product manager. A GPO setting that specifically addresses this problem was accidentally left out of the ViewPM.adm file included with View 5.0 build 481677. The policy setting is called “Excluded Processes”. The description of the setting is: “Excluded processes are processes whose i/o is ignored by Persona. Certain anti-virus applications might need to be added to prevent performance problems. If an anti-virus application does not have a feature to disable offline file retrieval during its on-demand scans, this setting will prevent it from unnecessarily retrieving files. However, changes to files/settings in the users’ profiles made by excluded processes are still replicated.” Using this setting eliminates the need to create any exclusions inside of FEP, so C:\Users will still be fully protected.

The solution for FEP is to use this GPO setting to exclude the FEP process MsMpEng.exe. Here is the replacement ViewPM.adm file. There is also a viewPM_adm_patch that I created with WinMerge, you can apply the diff to the ViewPM.adm file that installs with View 5.0.

Here are 2 screenshots of the missing setting.

Special thanks to Kevin Goodman at VMware for providing this solution!

Update 1/12/2012
I opened a ticket with Microsoft support and they advise that there is no way to prevent the download and scanning of offline files. They have escalated the ticket internally to look for any way this could be supported, but the engineer is setting expectations that there will be no resolution. It appears that you can not use personas with FEP unless you disable scans of C:\Users. That’s not a risk that I’m going to recommend taking, so it looks like it’s roaming profiles for my View clients who use FEP.

Update 1/10/2012
The support engineer assigned to my case came back with this:

I was able to replicate the behavior you saw while working with persona management and FEP server. The reason I was able to identify is on logon FEP is downloading all data to the local machine to be scanned and thereby causing the delay.

Our expectation is that virus scanners will ignore scanning offline files, but not a case with MS FEP. I was unable to find any such option with FEP client to ignore scanning offline files. Hence this can only be worked around by excluding the folder to be scanned on individual VMs. This does not however completely compromises security as the file share where the persona eventually will be stored is being protected with FEP anyway.

Persona management works by selecting/clearing offline file attribute for the contents of entire %userprofile% folder.

I opened a ticket with Microsoft support with the above information. Setting up an exclusion on C:\Users prevents realtime scanning on that folder and I don’t think I want to let a potential virus sit out there unchallenged until the profile syncs up to the file server.

1/1/2012
I am deploying a new View 5 setup and the client has Forefront Endpoint Protection. After enabling persona management for my Windows 7 image, I found that the logon process hung at “Welcome” for 3+ minutes.

I found this VMware communities thread suggesting that MS Forefront Endpoint Protection was the culprit. I enabled debug logging and tried logging on with FEP both enabled and disabled. The debug logs are identical other than the amount of time spent between log entries. With FEP disabled, files in C:\Users are touched quickly, less than 0.1 seconds between log entries. With FEP enabled, files in C:\Users have a 3-5 second delay between touches. This leads to the 3+ minute logon delay.

The VMware community post suggested excluding C:\Users from scanning – I tested that configuration and it does resolve the logon slowness problem – logon completes within 5 seconds and profiles are synced successfully. Obviously, this comes at the expense of the security of the environment – I wouldn’t go to production excluding the entirety of C:\Users from antivirus scans.

I’ll be opening up a VMware support ticket, but given the deadline I’m working under it looks like roaming profiles are in my near future. Disappointing because I was impressed with the speed of the View persona management when FEP isn’t in the way.

VMware View – Persistent / Non-Persistent

Posted on July 16, 2011 by pkremer

We are struggling with how to implement VMware View. If you use a persistent pool, you waste resources by having resources provisioned for users who aren’t doing any work at the time. You also run into problems maintaining the user profile – you can use a dedicated user disk, but how do you ensure a good backup? It’s also an administrative annoyance having to disconnect and reconnect user data drives. On the plus side, users can be given admin rights to install applications

With a non-persistent pool, desktops are spun up as needed based on demand, and they can be destroyed automatically when the user logs off. You are forced into using roaming profiles with folder redirection, which creates its own set of administrative difficulties. Users aren’t able to install applications as nothing is persistent, so the administrator has to install all apps inside the pool template. Alternatively, you can use application virtualization and try to ThinApp an application. However, my experience with ThinApp has been less than impressive. When it works, it works quite well. When it doesn’t work, it’s a baffling ritual of hocus pocus trying to get the app to work. In the end, it just doesn’t work for the majority of our software because the vendor won’t support ThinApp. When you call a 3rd party vendor for support for a problem and try explaning that it was installed via ThinApp, the call will often end with a statement that ThinApp isn’t supported.

Refusal to support ThinApp does sound a lot like when vendors refused to support apps installed in a VM – they eventually came around. But until that point, we’re stuck with what the vendor is willing to support.

Patrick Kremer

Technical perspectives from a VMware Field Engineer

Category Archives: Horizon View