Home > Blogs > VMware Consulting Blog > Tag Archives: AppStacks

Tag Archives: AppStacks

Cloning AppStacks and Modifying Scripts

Jeremy WheelerBy Jeremy Wheeler

Recently while working onsite with a client I discovered they needed to have local Windows accounts created upon AppStack attachment as required by their application. The customer didn’t want to go through the process of recreating the AppStack to achieve this. I was able to solve this problem by injecting scripts into the VMDK of the AppStack. These scripts are called at the time a volume is dynamically attached, or at various points during system startup and logon. They are used in order only if present in the AppStack or Writable volume. If not present in the volume the batch file will be skipped.

All batch files are in the root of the AppStack or Writable Volume. They are only accessible on a system without an agent.

For example, if you assign a volume to a Windows system and there is a user logged in, you would see the following steps—taken automatically—in chronological order:

  • prestartup.bat runs under Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.
  • startup.bat runs under Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.
  • shellstart.bat runs under Windows USER. If the volume is attached before the user logs in, this is called just before the Windows shell launches.
  • startup_postsvc.bat runs under Windows SYSTEM. This will only occur if there are services or drivers on the AppStack or Writable Volume.
  • logon_postsvc.bat runs under Windows USER. This will only occur if there are services or drivers on the AppStack or Writable Volume.
  • allvolsattached.bat runs under Windows USER. If multiple volumes are attached at the same time (i.e., during user logon), then this is called only once.

These scripts may contain any scriptable actions and are used to customize Windows desktop and application actions at various points in time during the system startup and user login processes. This is to ensure AppStack and Writable Volume data will function appropriately and provide the user with the best possible experience.

These scripts are case sensitive and should be utilized and/or modified with caution.

Batch File Details:

Optional wait times for each batch file may be configured. These are just part of the agent machine. Wait times are defined in seconds and all settings are stored as REG_DWORD registry entries in the following Windows registry path.

HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters

Registry keys may also be created on the agent machine using the command line interface.

Example:

reg.exe add HKLM\SYSTEM\CurrentControlSet\services\svservice\Parameters /v KeyValue /t REG_DWORD /d 60

End User System Batch Files

The following is a list of each batch file used on the end-user system.

  • prestartup.bat – Launched under Windows SYSTEM when a volume is dynamically attached or during system startup prior to virtualization being activated.
    Optional wait time key: WaitPrestartup (default do not wait).
  • startup.bat – Launched under the Windows SYSTEM when a volume is dynamically attached or during system startup. (Right after the volume is virtualized)
    Optional wait time key: WaitStartup (default do not wait).
  • startup_postsvc.bat – Launched under the Windows SYSTEM after services have been started on the volume. This is only called when there are services on the volume, which are needed to be started (not called unless there are services on volume).
    Optional wait time key: WaitStartupPostSvc (default do not wait).
  • logon.bat – Launched under the Windows USER at logon and before Windows Explorer starts.
    Optional wait time key: WaitLogon (default wait until it finishes).
  • logon_postsvc.bat – Launched under the Windows USER after services have been started. This is only called when there are services on the volume, which are needed to be started (not called unless there are services on volume).
    Optional wait time key: WaitLogonPostsvc (default do not wait).
  • shellstart.bat – Launched under the Windows USER when a volume is dynamically attached or when Windows Explorer starts.
    Optional wait time key: WaitShellstart (default do not wait).
  • allvolattached.bat – Launched after all volumes have been processed (so if user has 3 AppStacks, this will be called after all 3 have loaded).
    Optional wait time key: WaitAllvolattached (default do not wait).
  • shellstop.bat – Launched under the Windows USER when Windows session logoff is initiated, but before Windows Explorer is terminated.
    Optional wait time key: WaitShellstop (default do not wait).
  • logoff.bat – Launched under the Windows USER during Windows session logoff when Windows Explorer has terminated, but before the volume has disconnected.
    Optional wait time key: WaitLogoff (default do not wait).
  • shutdown_presvc.bat – Launched under the Windows SYSTEM when the computer is being shut down before services have been stopped.
    Optional wait time key: WaitShutdownPresvc (default do not wait).
  • shutdown.bat – Launched under the Windows SYSTEM when the computer is being shut down after services have been stopped.
    Optional wait time key: WaitShutdown (default do not wait).

Provisioning System Batch Files

The following is a list of each batch file used on the provisioning system

post_prov.bat – Launched at the end of provisioning to conduct any one-time steps that should be performed at the end of provisioning. Invoked at the point of clicking the provisioning complete pop-up while the volume is still virtualized.
Optional wait time key: WaitPostProv (default wait forever).

The steps needed to perform such an operation are outlined here.

App Volumes Update Method

**** Initial preparation

JWheeler Cloning AppStacks 1

  1. Select the source AppStack and click ‘Update.’
  2. Give the new AppStack a name, select the appropriate storage, append the path with the new AppStack name, and enter a description if needed.
  3. Select ‘Create’ and ‘Wait for completion’ or ‘Perform in the background.’
  4. Select ‘Update.’
  5. Once ‘Update’ is selected you will need to wait until the AppStack is cloned. Once completed refresh your App Volumes Manager interface.
  6. The new AppStack you created should be present and show the status of ‘Un-provisioned.’

**** Provision Updated AppStack

JWheeler Cloning AppStacks 2

  1. From the App Volumes Manager interface, select ‘AppStacks’.
  2. Select your newly created AppStack (the one you just modified).
  3. Select ‘Provision.’
  4. Enter the name of the provisioning virtual machine. The provisioning machine is typically a clean virtual machine with patches and limited applications installed.
  5. Select the provisioning virtual machine.
  6. Select ‘Provision.’
  7. Select ‘Start Provisioning.’
  8. Once the AppStack is attached to your provisioning machine open the console to that virtual machine.
  9. You will be greeted with a dialog box that says you’re now in provisioning mode.
  10. Select Explorer and change the view to show hidden files/folders.
  11. Navigate to “C:\SnapVolumesTemp\MountPoints.”

Note: Under MountPoints you will discover links. If you go into each link you will find a set of files such as batch scripts (startup.bat, etc.) You can make your changes at this point.

  1. Once you complete your changes, re-hide hidden files/folders.
  2. Select ‘OK’ on the App Volumes dialog to finish the capture process.
  3. Select ‘Yes’ to the installation complete dialog.
  4. Select ‘OK’ to the next dialog box, which will reboot the virtual machine.
  5. Once the provisioning machine has rebooted, login to complete the process.
  6. Select ‘OK’ at the ‘Provisioning successful’ dialog box.

**** Editing an AppStack VMDK outside the Update option

JWheeler Cloning AppStacks 3

  1. Select a virtual machine that does NOT have App Volumes Agent installed.
  2. Edit the settings of the virtual machine and add a drive. (Edit Settings > Add… > Hard Disk > Use an existing virtual disk)
  3. Navigate through the storage tree to your newly created AppStack and select the VMDK (i.e., \cloudvolumes\apps\<your new app>\<your new app.vmdk>
  4. Select ‘OK’ on the virtual machine settings interface to commit changes.
  5. You should now see a new drive letter representing the new AppStack VMDK. Proceed to make any customizations you need.
  6. Once finished, edit the settings again of the virtual machine (you can do this step with the virtual machine powered-on or off).
  7. Select the newly added hard disk (the new AppStack VMDK you added).
  8. Select the button ‘Remove.’
  9. Select the button ‘Remove from virtual machine.’
  10. Select ‘OK’ to commit changes to the virtual machine.

Note: If you receive an error message that the VMDK is in shared-mode you can do one of two options to resolve this.

  • Select ‘Rescan’ in the App Volumes Manager portal > Volumes > AppStacks tab.
  • Delete .metadata file where the VMDK resides on the datastore. This option is typically needed if you clone the AppStack from the datastore side and don’t use the Update method as outlined above.

Your AppStack is now ready to test.


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013

So You Virtualized Your Desktop Environment. Now what?

mmarx.phpBy Mike Marx

Most of my customers start with a low-risk user group consisting of a large number of users with identical application requirements. This is the common scenario when starting out on the virtual desktop infrastructure (VDI) journey and ‘testing the waters.’ With proper design efforts, initial implementations are highly successful.

I spend the majority of my consulting effort working with customers helping them create their initial VDI design. Designs can be simple or complicated, but they all utilize a common technical approach for success: understanding user requirements, and calculating infrastructure sizing. But I’m not blogging about technical calculations or infrastructure sizing. Instead I would like to address a VDI design challenge customers face as they expand their VDI design: user application assignments.

While resource requirements are simple to assess, calculate and scale, application delivery becomes increasingly challenging as more users are added to the design. VDI administrators struggle to manage increasing numbers of desktop users – each having unique application requirements.

Applications are easy to add to a large static group of user desktops using linked-clones. But when unique user groups are introduced, and application requirements change, administrators are confronted with the challenge of maintaining a large number of small desktop pools – or impacting large groups of users in order to change an application assignment.

So how do we design an effective stateless desktop and maintain application diversity amongst unique user groups? VMware Horizon AppVolumes is the answer.

Using AppVolumes, VDI designs become simple to understand and implement. Once applications are effectively removed from the VDI desktop, VDI administrators are left with a simple stateless desktop. But users aren’t productive with an empty desktop operating system; they need applications – and lots of them.

Without going into deep technical detail (there are excellent blogs on this topic already) AppVolumes captures the application files, folders and registry components, and encapsulates them into a transportable virtual disk called an AppStack. As the user logs on to a stateless desktop, the assigned AppStack(s) will automatically attach and merge the user’s applications with the desktop virtual machine.

Now users are presented with a stateless desktop that is uniquely assembled with all of their applications. AppVolumes’ attached applications interact with other applications— and the operating system—as if they were natively installed, so the user experience is seamless.

Now that applications are no longer an impediment to VDI designs, VDI administrators are able to support large groups of users and application requirements using the same stateless desktop pool. By following the KISS principle: “Keep It Simply Stateless,” AppVolumes will open the door to new design possibilities and wider adoption by users and IT administrators.


Mike Marx is a Consulting Architect with the End User Computing group at VMware. He has been an active consultant using VMware technologies since 2005.  His certifications include : VCAP-DTD, VCP-DT, VCA-WM, VCA-DT, VCP2-5 as well as being an expert in VMware View, Thinapp, vSphere and SRM.

App Volumes: Storage Migration for AppStacks

Jeremy WheelerBy Jeremy Wheeler

Inside of App Volumes you can accomplish a storage migration between different SANs using the feature called ‘Storage Groups,’ provided you have shared storage between App Volume Managers. If you don’t, I recommend creating a temporary LUN/Volume to accomplish this migration. If you are performing a migration on a large scale, such as 2X or more App Volume Manager instances, you will need to perform steps one through eight on each App Volume Manager instance.

Conceptual architecture:

JWheeler AppVolumes Manager Conceptual Architecture

 

To achieve a successful migration we will need to utilize a shared LUN/Volume between datastores. This can be an NFS or iSCSI datastore and will only be used temporarily to complete this process.

JWheeler AppVolumes Migration Setup

Stage 1: Migration Startup

  1. Select ‘Infrastructure’
  2. Select ‘Storage Groups’
  3. Give your storage group a name (my example: migration_temp)
  4. Check ‘Automatically Replicate AppStacks’ and leave ‘Automatically Import AppStacks’ unchecked. If you check the ‘Import AppStacks’ checkbox, you will need to do a lot of cleanup if you were using a temporary LUN to do this migration.
  5. Select ‘spread’ for your distribution strategy.
  6. Select your preferred template storage.
  7. Select ‘direct’ for storage selection.
  8. Select the checkbox of your local shared storage. This field will represent where you currently have the AppStacks you want migrated.
  9. Select the checkbox of your Temporary LUN. The temporary LUN is assumed empty or the AppStacks you want migrated over are not on the temporary LUN.
  10. Select ‘Create’ 

Once your storage group is created replication will begin immediately; it might take awhile depending on how many AppStacks you need to distribute within the storage group.

Stage 2: Cleanup

  1. After all AppStacks have been evenly distributed in the storage group, you can simply delete the storage group. This will not delete any AppStacks – it simply disassociates the logical bucket of resources. Both the source LUN and temporary LUN will still have the AppStacks.

Load the VMware vSphere® client and move any AppStacks from the temporary LUN to the permanent shared storage LUN, and then to the View Block.

JWheeler AppVolumes View Block

I want to dig further into explaining this process about moving AppStacks from the temporary LUN. App Volumes create pointers to all AppStacks residing on storage. This means in our example (shown above) when we replicate an AppStack between two points the inventory object in App Volumes Manager will consider all these locations as the AppStack living space. This also means that if you decide to delete an AppStack from inventory, ALL pointer locations will also be deleted. So, if you need to clean up the App Volumes Manager inventory in your Source Environment, you will need to copy, move, or detach the temporary LUN you created prior to deletion. The process for doing that is explained here.

JWheeler AppVolumes

a)      Move AppStacks from cloudvolumes/apps/* to a temporary folder /cloudvolumes/apps/tmp/* using the vSphere C# client, GUI, or vSphere command-line.
b)      Delete AppStacks from Source inventory.
c)      Move AppStacks from cloudvolumes/apps/tmp/* to a permanent shared storage in the target environment folder /cloudvolumes/apps/* using the vSphere C# client, GUI, or vSphere command-line.
d)      Select ‘Import AppStacks’ in App Volume Manager under Volumes > AppStacks.
e)      Select the LUN you moved all the AppStacks into (step c).
f)       Set the root path of where the AppStacks will live and select ‘Import.’

You can also use ‘vmkfstools’ if you have shell access to a host that can see the shared storage. This process is a lot more manual compared to using App Volumes Storage Groups, but you can still accomplish the migration using this method.

Execute the following syntax:

vmkfstools -i </source/location> </dest/location> 

This will copy the VMDK file in its current format from source to target.
(AppStacks VMDKs are Thin Provisioned by default).

Once you have copied the AppStacks you will need to ‘Import AppStacks’ from the App Volume Manager
(Volumes –> AppStacks –> Import AppStacks).

Reference this Knowledge Base for additional information when using the vmkfstools command:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1028042

For more information, be sure to check out the following Education Course:


Jeremy Wheeler is an experienced senior consultant and architect for VMware’s Professional Services Organization, End-user Computing specializing in VMware Horizon Suite product-line and vRealize products such as vROps, and Log Insight Manager. Jeremy has over 18 years of experience in the IT industry. In addition to his past experience, Jeremy has a passion for technology and thrives on educating customers. Jeremy has 7 years of hands-¬‐on virtualization experience deploying full-life cycle solutions using VMware, CITRIX, and Hyper-V. Jeremy also has 16 years of experience in computer programming in various languages ranging from basic scripting to C, C++, PERL, .NET, SQL, and PowerShell.

Jeremy Wheeler has received acclaim from several clients for his in-¬‐depth and varied technical experience and exceptional hands-on customer satisfaction skills. In February 2013, Jeremy also received VMware’s Spotlight award for his outstanding persistence and dedication to customers and was nominated again in October of 2013