Tuesday, 12 August 2014

EUC Training Options and Links



I wanted to summarise the training material available for End User Computing products from VMware. I also wanted to make sure that the latest versions available were listed together in one place. There is lot that is free.

Education Homepage: http://mylearn.vmware.com/mgrreg/index.cfm
EUC Learning Path: http://mylearn.vmware.com/mgrReg/plan.cfm?plan=47955&ui=www_edu

Before you get into any training a good place to start is to understand the VMWare EUC vision. Here is a good, recent video by Sanjay Poonen (EUC GM) that walks through this: https://www.youtube.com/watch?v=D6xeGuF2S0M


Horizon

Fundamentals

VMware Workforce Mobility Fundamentals:
Horizon View [V6] Mirage [V5] What's New:



Horizon View

Fundamentals

Horizon (with View) Fundamentals (v6.0):

Professional

Horizon (with View) Install, Configure, Manage (v6.0):

Advanced

View: Design Best Practices (v5.X):

Other Resources

Instruction Videos (v5.2): http://www.vmwarelearning.com/view/



Mirage

Fundamentals

Horizon Mirage Fundamentals (v5.X):

Professional

Horizon Mirage: Install, Configure, Manage (v4.0):

Other Resources

Instructional Videos: http://www.vmwarelearning.com/mirage/



ThinApp

Fundamentals

ThinApp Fundamentals (v5.X):

Professional

Application Virtualization with VMware ThinApp (v5):

Other Resources

Instructional Videos: http://www.vmwarelearning.com/thinapp/



Workspace Portal

Fundamentals

VMware Horizon Workspace Fundamentals [V1.8]:



vCenter Operations for View

Fundamentals

vCenter Operations Manager for View Fundamentals (v5.X):

Other Resources

VMware vCenter Operations Manager Fundamentals [V5.6]:



Tuesday, 29 July 2014

Persona Mgt and Folder Redirection


As a full explanation of the process I would recommend starting with the View Persona Management Deployment Guide as it also covers folder redirection: http://www.vmware.com/files/pdf/view/VMware-View-Persona-Management-Deployment-Guide.pdf


Below are the general settings that I would normally use for folder redirection and persona management with floating desktops. The puts the profiles in a Profiles share, creating a directory for each user. The redirected folders go into a User's share again creating a directory for each user. There is nothing stopping you having the profiles (persona management) and the redirected folders in the same share. You will just end up with two folders for each user (one for persona and one for documents).

Before you start you will need to setup a file share to host the user profiles and a separate file share to host the redirected folders. The process and security permission required are on page 232 of the View Admin Guide: http://pubs.vmware.com/view-52/topic/com.vmware.ICbase/PDF/horizon-view-52-administration.pdf#page=232

Persona Management
The first thing you will need to do is to Add in the ADM template into the GPO you have created. The View ADM files are on the View Connection Server in C:\Program Files\VMware\VMware View\Agent\bin\. The one we need for Persona Management is ViewPM.adm



Enable persona management, specify the persona repository location and tell it to override AD if configured. The format I normally use is: \\server\ProfileShare\%username%.v2 for Windows 7/ 8 desktops. This creates a Bob.v2 folder to store the persona in the profiles share.

Profiles are format version 2 when it is Win7 or 8 (actually Vista onwards). You can call this anything as long as it creates a different directory from the one we will define in Folder Redirection below and best practice is that we indicate what version the profile is (never know when a version 3 may come along).


Folder Redirection
Redirect the Documents using the standard Folder Redirection settings in the User Configuration. Note that this assumes you are using Loopback Processing as we will be applying settings to the user portion of the GPO.

The general format I use for each folder I want to redirect is \\server\UserShare\%username%\Documents



With Windows 7, I normally  also select the Pictures, Music, Videos, etc and explicitly set the properties for them to redirect.

You may want to also redirect the Desktop to catch any shortcuts or documents the users place there. Other ones to consider are the Favorites, Downloads, Start Menu and AppData (Roaming).


We then need to make sure that Persona Management excludes these folders from its replication. Back in the Persona Management settings.




Obviously tailor this list depending on what you have actually redirected in Folder Redirection. There may be other things in the persona that we would want to have replicate such as the Local Settings.

 


 

Monday, 8 April 2013

Min. Resource Requirements for a Horizon Workspace PoC or Lab

With the release of VMware Horizon Workspace many of us are evaluating it and testing this in our labs. When you install the vApp it creates 5 VMs each of which are allocated a certain amount of vCPU and memory which while sized for production can be overkill for some PoC and definitely lab environments.

To help with evaluating this is a resource constrained environment it is possible to reduce the resource allocation to each of the VMs after deploying the VM.

If you are only evaluating this is your lab you may be able to squeeze these settings down further to save resources. The one I would not touch is the Data-va as reducing it further is known to cause issues.

Test the changes to make sure it doesn't cause any timings issues and remember this is not supported.

Wednesday, 23 January 2013

Running Multiple Instances of the View Client

Have you ever wanted to launch multiple View instances as different users but from the same client?

I'll start by saying that this is unsupported and should not be used in production. 

This can however be very useful in set up and testing where you may want to remain logged into one desktop as an admin user and log in and out of another as a standard user.

What is supported is the use of command line parameters that you can pass to the View Client. If you open a CMD prompt and run "C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -? you get a list of the possible parameters.


This allows you to create short cuts with the following:

"C:\Program Files\VMware\VMware View\Client\bin\wswc.exe" -serverURL https://<connectionserver> -userName Test1 -domainName DEMO -password testpassword -desktopName "Pool Name"

Very useful as it stops us having to specify the test user, password, etc. each time, but we can only run a single instance of the View Client.

To run multiple instances of the View Client we can add an undocumented switch -Standalone. This allows us to have multiple instances of the View Client logged in as different users each in their own Window.


To do the equivalent on a MAC:

  • In Finder browse to Applications
  • Right click the VMware View Client and select Show Package Contents
  • Browse into Contents and MacOS
  • Double clicking on vmware-view will open a Terminal Window and launch a new instance of the View Client.


Just remember the use of the -Standalone switch and running multiple instances is unsupported.

Monday, 14 January 2013

Disconnect Idle Users in View

[Updated] Windows 7 64-bit corrections. While originally tested on Windows 32-bit there are some changes required for 64-bit Windows.


I was recently asked if there was a way to disconnect idle users from a View session. The motivation and use case was to free up shared or public thin clients so they weren't locked up and then inaccessible to other users.

I had a look around and found an excellent screensaver from GrimAdmin.com. This allows you to define an action to carry out when the screensaver kicks in and after a wait time has expired. It comes with predefined actions such as Logoff but also allows you to define an external process which allows us to call a process to disconnect the user. What was missing was an ADM template to make this easy to apply to a GPO but the author had documented the registry settings so I put one together.

There are three steps to configure this:

  1. Download and install the GrimAdmin screensaver
  2. Configure GPO personalization to enable the screensaver.
  3. Configure GPO to specify GrimAdmin actions.


Step 1

To get started, download the bits we'll need:
  • Download GrimAdmin Screensaver Operations here
  • Download the adm template here
Extract the scr file from the GrimAdmin file and install it into your desktops into the C:\Windows\Systems32 directory. In a View environment the easiest way is to copy it to the parent VM and recompose to get it on all the linked clones.

[Update] For Windows 64-bit copy the scr file to the C:\Windows\SysWOW64\ directory.

Step 2
Now we can configure our GPO to enable a screensaver, set the idle time to wait before starting the screensaver and which screensaver to run.

Under the User Configuration section browse into Polices, Administrative Templates, Control Panel, Personalization. Change your settings to match the values below.

The value for the Force specific screen saver should match the 8.3 name of the Screensaver from GrimAdmin. This should be Screen~1.scr but you can check by doing a DIR /X

[Update] For Windows 64-bit specify the whole path to the screensaver. C:\Windows\SysWOW64\SCREEN~1.SCR

Remember to set the number of seconds that you want to wait until the screensaver starts in the Screen Saver timeout. For testing I've got this quite low at 60 seconds in most environments this is going to be higher depending on how long you want to wait before considering a user idle.


Step 3

Now we need to configure the GrimAdmin Screensaver to carry out the operation we want. To start we need to add in the adm template you should have downloaded into our GPO. Right click the Administrative Templates under User Configuration and select Add. Browse to where you saved the adm template and select it.

You will now get and new section under the Classic Administrative Templates called Screensaver Operations in which we can set the various registry keys that control GrimAdmin's Screensaver.

Configure the Process that we want to run. To disconnect a user we can run the process c:\Windows\System32\tsdiscon.exe
Note that this will only disconnect the user session but will leave them logged into the View desktop.


[Update] For Windows 64-bit use c:\Windows\Sysnative\tsdiscon.exe Because the screensaver is a 32-bit process, the OS would try and redirect any call to a 64-bit process in System32 to the SysWOW64 directory by default. Using the alias Sysnative tells Windows to use System32 anyway.

Define how long we want to wait from the screensaver starting to when it executes the external process and disconnects the user.

Define a custom message to get displayed to the user warning them that they are about to get disconnected.
I use the following but use the variables and whatever will make sense to your users.

"No user activity has been detected for quite a while. You will be disconnected unless you cancel within %time_remaining% seconds."

The other settings I used was to increase the font size of the message to make it a bit more noticeable. Test this though to make sure your message fits in the window with your font size.


That's it. When the group policy is applied when the user logs they should now get the screensaver set and they should be unable to change it.

After being idle for the defined period in the Screen saver timeout they will get the following message.

This will then countdown the number of seconds defined in the Delay In Seconds. If they do nothing they will get disconnected. If they click Cancel they reset the idle clock.

Wednesday, 5 December 2012

Using Sysprep with View

Occasionally it is necessary to use Sysprep instead of Quickprep when creating a desktop pool with View. This usually is because of some legacy software requiring unique local computer identifiers (SIDs). I recently got asked about it because of some older antivirus software that needed it to centrally manage its in-OS agents.

A comparison of the two customization techniques can be found in the View Administration Guide on pages 95 and 96. KB article 2003797 gives a quick table of the differences:

FunctionQuickPrepSysprep
Removing local accountsNoYes
Changing Security Identifiers (SID)NoYes
Removing parent from domainNoYes
Changing computer nameYesYes
Joining the new instance to the domainYesYes
Generating new SIDNoYes
Language, regional settings, date, and time customizationNoYes
Number of reboots01 (seal & mini-setup)
Requires configuration file and Sysprep  NoYes

To setup and deploy a pool using Sysprep the high-level steps are as follows:

  1. Copy the Sysprep files to the vCenter server (Note that this is only required for Windows XP as Windows 7 comes with sysprep). Full details on this are in KB article 1005593.
  2. Create a Guest Customization Specification in vCenter.
  3. Add a desktop pool and tell it to use sysprep and the guest customization spec you have created.


Create a Guest Customization Specification

  • In vCenter from the Home page select the option for Customization Specification Manager.
  • Add a New customization and on the Properties page enter a name. DO NOT use a custom sysprep answer file.
  • Continue through the wizard until the Computer Name page. Set this to use the virtual machine name.

  • Step through the wizard entering license keys, administrator password, time zone, etc until you get to the Network page.
  • Make sure you leave the network at the default of typical settings. This will then use DHCP.
  • On the Workgroup or Domain page leave this as the default. Any domain / administrator information entered here is not used. Instead the VM is joined to the domain using the guest customization settings defined in the pool settings through View Manager.

  • On the last page Operating System Options make sure that the Generate New Security ID (SID) is checked. After all the whole reason we are using Sysprep is because unique SIDs are required for our use case.

  • Finish the wizard.

Add a desktop pool

  • In View Manager add a desktop pool as you would normally. The only deviation from using Quickprep comes on the last page for Guest Customization.
  • Select the Domain. This list (normally only one in most environments) is what you defined when you configured the vCenter server in View Administrator and defined the Domains for View Composer. This settings is what will control which domain is joined and which credentials are used when customizing the linked clones.
  • Select the appropriate AD container as normal.
  • Select the option to Use a customization specification (Sysprep) and select the spec you created earlier.


  • When you complete the wizard your pool should deploy although provisioning can be a bit slower than using Quickprep especially as there is an additional reboot of the linked clone required.




So what are the steps that take place when View customizes with Sysprep?

  1. Once the linked clone disks have been created, View Manager puts the VM into the Customizing state.
  2. View Manager calls the vCenter API customizeVM_Task to customize the VM with the customization specifications. 
  3. View Manager powers on the linked clone.
  4. Inside the Guest OS on the linked clone, the View Composer Agent sees that it is starting for the first time and calls NetJoinDomain with the machine password cached on the internal disk. 
  5. The machine is now joined to the domain.
  6. Sysprep is now run on the linked clone from within the guest.
  7. The  View Composer Agent waits for Sysprep to finish before notifying the View Agent that customization is complete. Then the View Agent sends a message to the View Manager server.
  8. The View Manager Server powers off the clone and takes a snapshot of the customized, powered off clone (to give us our refresh state).
  9. View Manager puts the linked clone into the Provisioned state. If the VM is then powered on, it moves into the Available state.

Full details of these steps can be found on Andre Leibovici's blog.




Friday, 30 November 2012

Assigning ThinApps by group membership using the SDK

The SDK for ThinApp recently got an update to version 4.7.3 and this prompted me to revisit login scripts I had previously written using thinreg.exe

Download from here: http://communities.vmware.com/community/vmtn/developer/forums/thinapp

The SDK offers lots of advantages over thinreg and will be faster as it does not require Windows to shell out.

The one bit of preparation we need to do is for any desktop going to register ThinApps. With a View environment this is quite straightforward as you can do the following steps to the Master or Parent VM
  1. Copy the ThinAppSDK.DLL (from the SDK download) into the Windows\System32 directory
  2. In a CMD prompt (with Administrator rights) register the DLL with: REGSVR32.EXE THINAPPSDK.DLL
This now allows us to reference ThinApp objects and carry out different operations on them. Full details on the functions are in the PDF document that comes with the SDK download. The most common operations and the ones I was interested in to replace thinreg.exe are Register and UnRegister. In a VBScript we need the following:

First we need to create an object so we can call the ThinApp commands:
 Set TAManagement = CreateObject("ThinApp.Management")

We also need to create a  variable to hold the Package while we work with it.
 Dim Package

We can now set this variable to the thinapp we are going to work with:
 Set Package = TAManagement.OpenPackage(\\server\share\Adobe Reader 9.exe)

This now allows us to Register a package with: Package.Register 1

And Unregister a package with: Package.UnRegister

I put this together into this login script 
Here's a link to download the login script. just remove the .txt extension to leave this as a .vbs file - https://sites.google.com/site/vkiltblog/view_login_sdk.vbs.txt

Save the text down in a vbs file and add it into the GPO that you should have created and linked to the OU that houses the View desktops. See my previous post on details on setting up a GPO for View: GPO's for View

You may look at the script and ask why I'm not using wildcards, why I'm checking for group membership and why I'm checking for registry entries. The simple answer is to speed up the execution of the login script and provide minimal disruption to the user on login. If we use wildcards or don't check the registry then subsequent registers will always be attempted. This can cause the screen to flash and slow down the login. I prefer to specify the thinapp, the group entitled and the registry key so we don't even attempt a register or unregister if it's not necessary. It also makes unregister's cleaner.

To make this repeatable I put the register and unregister in functions and then defined the variables to call that with.

For each application we define the following:
 ADGroup = "Adobe Reader"
 FileName = "\\server\share\Adobe Reader 9.exe"
 RegKey = "Software\Thinstall\ThinReg\Adobe Reader 9_28503025"
 CheckReg = True
 DebugMsg = False

where:
 ADGroup = The AD Group that is entitled to the app
 FileName = "Full name and path of ThinApped exe"
 RegKey = "Registry Key created when registered under HKCU"
 CheckReg = True or False, where True will check the registry to see if the ThinApp has already been registered
 DebugMsg = True or False, where True will popup message on register or unregister

We can then call the function for each application to either register, unregister or do nothing.
 RegUnRegApp ADGroup, FileName, RegKey, CheckReg, DebugMsg

You can also change the DebugMsg variable to True and you will get a pop up message on each register or unregister. You can also turn off the Registry Check by changing CheckReg to False (this is useful when registering a new application and you don't know what registry key will get created by the register). Note that when we don't check the registry each time a user logs in, we will attempt to either register or unregister based on their group membership every time.

More scripting examples can be found here.