Cloning AppStacks and Modifying Scripts

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 go through 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 agent.

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

prestartup.bat

runs under the Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.

startup.bat runs under the Windows SYSTEM. If the volume is attached from boot, this will run when SVSERVICE starts.

shellstart.bat runs under the 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 the Windows SYSTEM. This will only occur if there are services or drivers on the App Stack or Writable Volume.

logon_postsvc.bat runs under the Windows USER. This will only occur if there are services or drivers on the AppStack or Writable Volume.

allvolsattached.bat runs under the Windows USER. If multiple volumes are all 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 a command line.

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 the 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 needing 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 needing 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 shutdown 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 shutdown 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 which 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

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

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 your 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 AppStack “Update” option

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.