Create GRP templates

You can create custom GRP templates for your applications or component dependencies. Custom templates help when a common application is deployed to multiple instances, with each instance potentially having different configurations or unique data.

A trusted template is a .zip file that contains configuration files and other data along with a .cat file. Custom untrusted templates can be in .zip files or a folder. A sample template named Sample Template is included with the EMP installation. You can find the sample template in the default EMP installation directory of C:\Program Files (x86)\AWS\EMP.

Templates are loaded from the C:\Program Files (x86)\AWS\EMP\Templates directory. To use the provided sample template, copy the Sample Template folder into the C:\Program Files (x86)\AWS\EMP\Templates directory and launch GRP.

Required files

The following files are required in a GRP template:

• _metadata.json

• evaluate.ps1

Optional files

The following files are optional in a GRP template:

• post-packaging.ps1

• Content directory

  • TemplateAddedFiles.json

  • TemplateAddedContent.json

  • TemplateIgnoredContent.json

  Depending on the requirements of the application, you may need some or all of the component files listed above. To figure out which files are required, you must understand what you want to accomplish by using a template. A template can be used to modify the files, directories, registry keys, services, and COM+ in any package created by using GRP. You can do perform these tasks by using the Content directory JSON files and a post-packaging PowerShell script as an option to modify the created package.

GRP template files

The sections below contain detailed information about the GRP template files.

_metadata.json

The _metadata.json file is required. It provides the template metadata that is displayed by the tool.

The following properties are required:

• name

• template_type – This can be set to Application or Component.

• version

The following code is an example of a _metadata.json file:

{
    "name":"Sample Template",
    "description":"EMP Sample Template #1",
    "template_type":"application",
    "author":"AWS",
    "version":"1.0"
}

evaluate.ps1

The evaluate.ps1 file is required. It is a script that returns a boolean to inform GRP whether the template can be applied. It can also set environment variables that can be used to expand the paths in content files.

Example application installation location:

$installLocation = "C:\\Program Files\\MyTemplateApplication"

The following code is an example of how to set a new environment variable with an application path:

$env:MYAPP_PATH = $installLocation
return Test-Path -Path $sqlInstallLocation

In the example above, whether or not the template can be applied depends on the existence of an application folder. An environment variable will be created for the application path, which is used on the TemplateAddedFiles.json. Several methods are used to verify the applicability of the template, including checking the registry keys, paths, and shortcuts. The script must return a boolean.

Whether the component template can be applied depends on the GRP data that is selected and discovered. For this reason, the evaluate script has two cmdlets that retrieve all the GRP files and registry keys:

• Read-GRPFiles

• Read-GRPRegistryKeys

• Test-GRPPath -Path – The path is the file or folder path. This returns a boolean.

The $template variable can be used to share information between the evaluate and post-packaging scripts.

The following code is an example that uses the functionality described above:

$grpFiles = Read-GRPFiles
$grpKeys = Read-GRPRegistryKeys
$template.HasLogs = Test-GRPPath -Path “C:\ApplicationLogs”
$template.InstallFullPath = $grpFiles -match "InstallFullPath"
return ($grpFiles -match "componentfile") -and ($grpKeys -match "componentregistry")

post-packaging.ps1

The post-packaging.ps1 file is optional. It runs after the compatibility package is generated in order to change the generated package. It contains a parameter that is set to the location of the GRP package folder.

The script can add software installation and uninstallation steps to the DeploymentScript.xml file of the package. DeploymentScript.xml can execute steps during the package installation and uninstallation. There are two cmdlets available for this:

• Add-InstallStep

• Add-UninstallStep

The cmdlets accept the following arguments:

• PackageFolder (mandatory) – GRP package folder. This is passed as a parameter to the post-packaging.ps1 script.

• Path (mandatory) – Path that contains the program that you want to run.

• WaitConditionTimeout – Time, in seconds, to wait if the WaitCondition property is set to Exit. Zero (0) indicates to wait indefinitely. The deployment will display an error if the process fails to close within the specified WaitConditionTimeout time.

• WaitCondition – Determines whether the deployment should wait for the executable to finish before continuing with the deployment. You can specify:

  • None – The deployment does not wait for the executable to finish. It runs the executable and continues with the deployment.

  • Exit – The deployment waits for the executable to finish before it continues the deployment.

• ProcessWindowsStyle – Determines whether the program UI should be visible. You can specify:

  • Normal – Shows the program UI.

  • Hidden – Hides the program UI.

• Order – Determines the sequence of the tasks. For example, you can specify 0, 1, 2, and so on.

• PreInstall – Installs the specified programs before installing the Windows services from the package. By default, the services are installed first.

The following code is an example of a post-packaging.ps1 script:

param($packageFolder)

New-Item New-Item $packageFolder\test.txt

Set-Content $packageFolder\test.txt $template.test

Copy-Item Payload -Destination $packageFolder -recurse
Add-InstallStep -PackageFolder $packageFolder -Path %defaultdir%\Payload\test.exe -Args "/q"
Add-UninstallStep -PackageFolder $packageFolder -Path %defaultdir%\Payload\test.exe -Args "/u /q"

In the example above, GRP assigns the location of the package to the $packageFolder variable. The variable is used as a parameter in the subsequent commands. In the example, a simple text file is created inside the package and text from the variable $template.test, which is defined in the evaluate script, is added to it. The package deployment is modified with the Add-InstallStep and Add-UninstallStep lines.

For more information, see Managing EMP custom configurations.

Content directory

Contains JSON files with files, directories, services, COM+, and exclusion rules that are used by GRP when an application is packaged. Paths can have environment variables that are expanded by GRP.

Content directory is optional and can include the following files:

• TemplateAddedFiles.json (optional)

  List of files and directories.

  Example

  [
    {
      "Path": "c:\\MyApp\\MyApp.exe",
      "IsFolder": false
    },
    {
      "Path": "%MYAPP_PATH%",
      "IsFolder": true
    }
  ]

  GRP uses these files in the discovery step.

• TemplateAddedContent.json (optional)

  List of registry keys, environment variables, or COM+ applications.

  Example

  {
    "Keys": [
      "HKLM\\Software\\MyAppKeys"
    ],
    "COMPlusApps": [
        {
        "Id": "a055b67b-0d22-4bbe-8f91-738f49b92d7a",
        "Name": "MyComPlusApp"
        }],
    "EnvironmentVariables": {
      "MyAppEnvVar":  "MyEnvVarValue"
    }
    
  }

  This content is added after the GRP discovery. The COM+ application must be present or the package will fail.

• TemplateIgnoredContent.json (optional)

  List of files, directories, and registry keys that are ignored during the GRP discovery.

  Example

  {
    "Files": ["C:\\Windows\\NativeDriver.dll"],
    "Folders": ["%ProgramData%\\TempSettings"],
    "RegistryKeys": ["HKLM\\Software\\Microsoft\\NotPortableKeys"]
  }

  After you create a template, see Use GRP templates. GRP must be restarted after the templates are updated.