Post-scripts in VMware Mirage

For many operations VMware Mirage allows to run so-called post-scripts.
Post-script are scripts that run on the endpoint after one of the following operations is completed:

  • Windows migration
  • Base layer provisioning
  • Base layer assignment
  • App layer deployment

A post-script allows you to run scripts and programs and do customisations.

Practical use cases are:

  • Delete the Windows.old directory after a Windows migration
  • Customise configuration files based on computer name
  • Install OEM software based on the specific hardware type
  • Deploy applications that are not yet compatible with app layers
  • and many more

All post-scripts are located under %ProgramData%WanovaMirage Service and need to be included in the base layer respectively in the app layer in case of the post-app layer deployment script.
Below you find an overview of the different script names that are used.

Script file name Execution time
post_migration.bat Post-Windows migration
post_provisioning.bat Post-Base Layer Provisioning
post_core_update.bat Post-Base Layer Assignment
post_layer_update_*.bat Post-App Layer Deployment

By default the post_migration.bat and a file called post_bi_update.bat are located inside the %ProgramData%WanovaMirage Service directory. While you can freely modify the post_migration.bat to execute programs and scripts after a Windows migration it is highly recommended not modify the post_bi_update.bat script. The post_bi_update.bat script is more or less just a wrapper for the post_provisioning.bat and post_core_update.bat.

So, if you want to run scripts after a base layer provisioning or assignment you first have you create the corresponding script (post_provisioning.bat or post_core_update.bat) inside the %ProgramData%WanovaMirage Service directory. Those two script are call by the post_bi_update.bat so there is no need to modify this file directly.

Inside the scripts you can basically do whatever you want you just have to be aware of the following:

  1. The scripts and therefore everything you do inside the scripts are executed in the context of the system account
  2. Make sure your script returns a proper error code. Return a zero (0) if the script execution is successful. Everything else is interpreted as an error and logged as such in the Mirage event log.
  3. By default there is a 300 second (5 minute) time out for post-scripts. If the script isn’t finished during this timeframe Mirage will no longer wait for the script and proceed.

MiragePostScriptErrorMiragePostScriptTimeout
The screenshots above showing a post-script error and time out message in the Mirage event log.

While most scripts are placed inside the base layer the post-app layer deployment script needs to be included in an app layer. During the app layer recording process create a file called post_layer_update_.bat in the folder %ProgramData%WanovaMirage Service. Of course you need to replace the asterisk () with a unique name. You have to make sure that each app layer has a unique script name.

Example: post_layer_update_firefox22_0485345.bat

Unfortunately troubleshooting post-scripts can be bit cumbersome as you have no chance to see the script execution interactively. Therefore it is recommended to implement logging functionalities in your script so that each step is recorded in a log file. A perfect location for log files created by post-layer scripts is the Mirage service log directory located at %Program Files%WanovaMirage ServiceLogs. Just make sure you choose a unique log file name.

2 thoughts on “Post-scripts in VMware Mirage

  1. Hi Tim,

    thanks for sharing your knowledge in this article. Do you know if it is possible to increase the default timeout value for post-script (300seconds)?

    I haven’t found anything in the VMware Mirage Documentation…

    Regards,
    Pascal

    Like

    1. Sure, you have to change the postScriptTimeOutInSeconds parameter in the Wanova.Desktop.Service.exe.config of the Mirage client. Default value is 5 minutes (300 seconds) but you can change it to whatever you want. I went up to 1800 seconds (30 minutes) without any problems.

      This change can be done centrally using a CVD policy. Have a look at “How to disable the Horizon Mirage client upgrade balloon” to see how this can be done.

      Hope this helps
      Tim

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s