The Corinth 3D app downloads its content (such as 3D models, videos and deep zooms) to the computer in order to show it to the user. The app is able to share these data between users on one computer to minimize storage space usage and prevent unnecessary downloads. To make this possible, you need to allow application data to be shared between users for UWP apps. You can do so for example via GP or Registry value.

    1. Make sure you have sufficent privileges.
    2. Open GP_LocEdit, e.g. from the Start menu by typing gpedit.msc and pressing Enter.
    3. Go to GP_AppPkgDeployment settings by selecting GP_LocalCompPolicy -> GP_CompConfig -> GP_AdminTemplates -> GP_WinComponents -> GP_AppPkgDeployment in the left side of the GP_Edit window. Local Group Policy (Data Sharing)
    4. In the GP_AppPkgDeployment settings, double-click GP_AllowWinAppShare.
    5. Select GP_Enabled in the top-left part of the window.
    6. Click Gen_Apply, then Gen_OK.
    1. Make sure you have sufficent privileges.
    2. Open GP_MgmtEdit, e.g. in the GP_Mgmt window, right-click a GP_Obj of your choice and click Gen_EditMore.
    3. Go to GP_AppPkgDeployment settings by selecting GP_CompConfig -> GP_Policies -> GP_AdminTemplates -> GP_WinComponents -> GP_AppPkgDeployment in the left side of the GP_Edit window. Active Directory Group Policy (Data Sharing)
    4. In the GP_AppPkgDeployment settings, double-click GP_AllowWinAppShare.
    5. Select GP_Enabled in the top-left part of the window.
    6. Click Gen_Apply, then Gen_OK.

  2. In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateManager, set the value of the key AllowSharedLocalAppData to 1.

    You can do this for example via:

    • RG_Edit
    • .reg file
    • Win_Cmd (Cmd) or PowerShell

      Example (Cmd/PowerShell)
      REG ADD 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager' /t REG_DWORD /f /v 'AllowSharedLocalAppData' /d '1'

    • ActiveDirectory GP_Edit -> GP_CompConfig -> GP_Preferences -> GP_Registry.

Sideloading a UWP app means installing it outside Microsoft Store using its installation package. You can get the Corinth 3D installation package for Sideloading, however, for its installation to work you must first make sure that Sideloading is enabled on your machine. You can enable Sideloading for example via WS_WinSett, GP or Registry value.

    1. Sign in as an administrator.
    2. Open the Start menu.
    3. Click gear icon to open WS_Sett.
    4. Select WS_UpdateAndSec category.
    5. Select WS_ForDevel at the bottom of the list on the left side of the window.
    6. Within the section WS_UseDevelFeat, select the WS_Sideload option. Settings For developers
    7. Examine the notice and confirm the changes.
    1. Make sure you have sufficent privileges.
    2. Open GP_LocEdit, e.g. from the Start menu by typing gpedit.msc and pressing Enter.
    3. Go to GP_AppPkgDeployment settings by selecting GP_LocalCompPolicy -> GP_CompConfig -> GP_AdminTemplates -> GP_WinComponents -> GP_AppPkgDeployment in the left side of the GP_Edit window. Local Group Policy (Sideloading)
    4. In the GP_AppPkgDeployment settings, double-click GP_AllowAllTrustedApps.
    5. Select GP_Enabled in the top-left part of the window.
    6. Click Gen_Apply, then Gen_OK.
    1. Make sure you have sufficent privileges.
    2. Open GP_MgmtEdit, e.g. in the GP_Mgmt window, right-click a GP_Obj of your choice and click Gen_EditMore.
    3. Go to GP_AppPkgDeployment settings by selecting GP_CompConfig -> GP_Policies -> GP_AdminTemplates -> GP_WinComponents -> GP_AppPkgDeployment in the left side of the GP_Edit window. Active Directory Group Policy (Sideloading)
    4. In the GP_AppPkgDeployment settings, double-click GP_AllowAllTrustedApps.
    5. Select GP_Enabled in the top-left part of the window.
    6. Click Gen_Apply, then Gen_OK.

  3. In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock, set the value of the key AllowAllTrustedApps to 1.

    You can do this for example via:

    • RG_Edit
    • .reg file
    • Win_Cmd (Cmd) or PowerShell

      Example (Cmd/PowerShell)
      REG ADD 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager' /t REG_DWORD /f /v 'AllowSharedLocalAppData' /d '1'

    • ActiveDirectory GP_Edit -> GP_CompConfig -> GP_Preferences -> GP_Registry.
System language (localized settings items):

Advanced installation manual

This manual is intended to be used mainly by school IT administrators as it provides some tips on how to set up Corinth 3D in school environments (i.e. for multiple users and/or on multiple computers with an effortless activation and appropriate update policy). It also presents a working sample solution for Corinth 3D deployment, demonstrating how to use all the described features in practice (using PowerShell).

Related Windows features

datasharing_setup
sideloading_setup

Installation methods

There are various ways to install the Corinth3D app. You can find details about some of them below, which should help you choose the way that best suits your workflow and leverages the tools you are already familiar with.

Microsoft Store is the standard source of Universal Windows Platform (UWP) apps, such as Corinth 3D. Corinth 3D is available on Microsoft Store, as well as Microsoft Store for Education and Microsoft Store for Business.

You can get Corinth 3D from Microsoft Store with some limited content unlocked for free. If you wish to unlock more of its content, you need to purchase a license. After you have purchased a license, you will be given a License Key. You can unlock the content by entering your License Key within the app. Alternativelly, you can use the auto-activation feature, even though it's most convenient when coupled with Sideloading rather than installation from Microsoft Store.

datasharing_setup

If, for whichever reason, you prefer not to use Microsoft Store, you can still install Corinth3D without it. When you install a UWP app outside the Microsoft Store, you are Sideloading the app. The Corinth 3D app is ready to be Sideloaded, if that suits your needs. Installation package may come as a file with one of the following extentions: appx, appxbundle, msix or msixbundle. You will need the package for Corinth 3D to Sideload the app, along with the dependency packages. You can obtain the necessary packages if you have purchased a license.

sideloading_setup

You can Sideload the app just by clicking the installation package. This will open the App Installer tool which will guide you through the installation process.

App Installer

App Installer itself is a UWP app, so if it is not already on your computer, you can get it from Microsoft Store. If you are not able or willing to do so, you can install the Corinth 3D app using PowerShell (see the sections below).

The app will be installed for the current user only and you will need to go through the configuration steps (such as App Data Sharing, activation and Update Strategy settings) by hand.

The Add-AppxPackage cmdlet can be used to add an app for the current user, along with all necessary dependency packages. It can also be used to update an already installed app, presuming that the Family Name of the existing app and the app being installed are the same.

Example (PowerShell):
Add-AppxPackage -Path ".\Corinth3D_Sideload_x64.appxbundle" -DependencyPath ".\Dependencies\x64\Microsoft.NET.Native.Framework.1.3.appx",".\Dependencies\x64\Microsoft.NET.Native.Runtime.1.4.appx",".\Microsoft.VCLibs.x64.14.00.appx"

Note: While using the Add-AppxPackage cmdlet, you need to install (add) the app for each user individually.

The Add-AppxPackage cmdlet can also be used to register the app for a current user, if the app has already been installed on the computer. No installation package is needed in this scenario.

Příklad (PowerShell):
Add-AppxPackage -RegisterByFamilyName -MainPackage "Corinth.Corinth3D_wv8kxjmt4maqr"

The Add-AppxProvisionedPackage cmdlet adds an app to a Windows image using the DISM (Deployment Image Servicing and Management) tool. The app is then added for every user on the machine, including those created in the future, just as the default Windows apps (e.g. Calculator, Calendar, Mail etc.) are added to them.

Note: You must specify the target Windows image. Typically, you want to affect the current (running) environment, which you can specify by the parameter -Online. Alternativelly, use the -Path parameter to specify the location of a different mounted Windows image.

Note: The cmdlet assumes you to provide an app license file. This is NOT the license input file to unlock the content of the Corinth 3D app (which you can provide to the app right after the installation to leverage the auto-activation feature). If you don't have one (which is probably the case while Sideloading the Corinth 3D app), you need to explicitly state to skip the license using the -SkipLicense switch.

Example (PowerShell):
Add-AppxProvisionedPackage -Online -PackagePath ".\Corint3D_Sideload_x64.appxbundle" -DependencyPackagePath ".\Dependencies\x64\Microsoft.NET.Native.Framework.1.3",".\Dependencies\x64\Microsoft.NET.Native.Runtime.1.4.appx",".\Microsoft.VCLibs.x64.14.00.appx" -SkipLicense

Note: It may take some time until the app is added for an additional user after they log in.

Note: When unistalling a provisioned app from the computer, you need to un-provision it first, and then remove it from all existing users.

If you want to use PowerShell to install the Corinth 3D app, it is convenient to create a PowerShell script rather than run the individual cmdlets. The script can not only install the app (using one of the cmdlets above), but also set up all the related or pre-requisitory settings.

Recommended steps for Corinth 3D app installation:

  1. Enable Sideloading.

    Example (Cmd/PowerShell):
    REG ADD 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock' /t REG_DWORD /f /v 'AllowAllTrustedApps' /d '1'

    sideloading_setup
  2. Install the app (either adding it for a single user or provision for all user).
  3. Enable Data Sharing (highly recommended).

    Example (Cmd/PowerShell):
    REG ADD 'HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager' /t REG_DWORD /f /v 'AllowSharedLocalAppData' /d '1'

    datasharing_setup
  4. Provide License Input file for auto-activation (optional) - see below.
  5. Set an Update Strategy (optional) - see below.
  6. Check the result and log progress (optional).
All of these steps can be executed by the PowerShell script itself, however, you can do some of them using different tool of you choose so (see details by clicking the individual steps).

Corinth Installation Script provides a working example of a PowerShell script which could be used to install the Corinth 3D app, demonstrating all of the above-mentioned steps in practice.

After you have finished the script, you can launch it manually or use a management tool to run it automatically upon a system event (such as system startup or user logon). See more in the Mass deployment section.

License activation

You can get the Corinth 3D app with some limited content for free. However, you have to purchase a license to unlock more of its content. Additional sections of the app's content are unlocked after the license is activated.

It takes one license per computer regardless of the number of users using the app on that particular computer. If you have Data Sharing enabled, you only have to enter the code once and the content is made available to all users on the machine.

After you have bought a license, you get your own License Key. Upon entering it within the app, the license is activated and the respective content is unlocked. Click the CC_GetFullVersion button, then insert your License Key and click CC_InsertLicKey. License Key field

Other than inserting the License Key manually, the app may be provided with a License Input file to automatically unlock the content during the next launch, without the need to specify the license key manually. It is particularly convenient if you are mass-deploying the app, for example Sideloading it using a script, as shown by the Corinth Installation Script sample.

The app will be expecting the License Input file (named license_input, without any extension) in one of the following locations (be aware that there are some caveats to each of them):

  • Local app data folder: %LOCALAPPDATA&\Packages\Corinth.Corinth3D_wv8kxjmt4maqr\LocalState

    Warning: The local app data folder is not shared between users. Each user has their own which is not accessible by other users. This means that in order to activate the license and unlock the content, the app must be launched by the user in whose local app data folder the License Input file is present.

  • Shared app data folder: %PROGRAMDATA%\Microsoft\Windows\AppRepository\Families\Corinth.Corinth3D_wv8kxjmt4maqr\SharedLocal

    Warning: App Data Sharing needs to be enabled for the app to use the shared folder. Furthermore, the shared folder is created during the first launch of the app and is not available until then. It is, however, shared which means that the license will be activated regardless of the user who launches the app.

  • App installation folder

    Warning: The app installation folder is both shared and available right after installing the app, however, it is typically set as read-only to majority of users including administrators. The License Input must therefore be included inside the installation package or you have to use system privileges to copy the License Input file to the installation folder.

Updates

If there is a new version of the Corinth 3D app avalable, it can be updated manually from the menu accessible by clicking the top-right icon -> CC_About -> CC_CheckUpdates. Corinth 3D menu Update button

If you have installed the app from the Microsoft Store, updates are handled automatically. If, however, you have Sideloaded it, the app allows you to set the way it behaves when handling updates.

There are 3 Update Strategies to choose from - select one depending on who should typically be the person to initialize an upgrade of the app:

  • User: When the app detects an update, it prompts the user who can then update the app by clicking a button. The user has control over the moment the app updates, so that the app doesn't update at an inappropriate time. Only if the app is still not updated weeks after the initial prompt, the update is forced.
  • Admin: When an update is rolled out, an email is sent to the admin to update the app and there is no prompt to the user. The admin should then perform a manual update or deploy a new version of the app at the earliest appropriate moment. The motivation behind this to give the admin control over the state of the machine, so that the users don't change it behind his back. Only if the app is not updated within longer period of time since the update was detected, it shows a prompt to users instructing them to tell the admin to update the app. If the app is still not updated weeks after the initial prompt, the update is forced.
  • Force: The update is carried out automatically without prompting anyone. This might be useful if you wish not to bother with the updates at all, but it gives you no control over the time of the update.
To apply the Strategy of your choice, create a Settings.xml file with following structure:
Example (XML):
                                    
        <?xml version="1.0"?>
        <UpdateSettings>
            <Strategy>Admin</Strategy> <!-- User, Admin or Force -->
        </UpdateSettings>

Note: You can use "User" or "Force" strategy instead of "Admin" which is used in the example above.

Note: If you provide no Update Strategy, the "User" Update Strategy will be used as default.

You then need to place the file into one of the app data folder (mind their respective limitations):

  • Local app data folder: %LOCALAPPDATA&\Packages\Corinth.Corinth3D_wv8kxjmt4maqr\LocalState

    Warning: The local app data folder is not shared between users. Each user has their own which is not accessible by other users and the app is using it only when it runs under that particular user. This means that if you place the file specifying an Update Strategy to a user's app data folder, the settings will only be applied for that particular user.

  • Shared app data folder: %PROGRAMDATA%\Microsoft\Windows\AppRepository\Families\Corinth.Corinth3D_wv8kxjmt4maqr\SharedLocal

    Warning: App Data Sharing needs to be enabled for the app to use the shared folder. Furthermore, the shared folder is created during the first launch of the app and is not available until then. It is, however, shared which means that the settings will be the same for all users, if you choose to put the file there.

  • App installation folder

    Warning: The app installation folder is both shared and available right after installing the app, however, it is typically set as read-only to majority of users including administrators. The settings file specifying the Update Strategy must therefore be included inside the installation package or you have to use system privileges to create that file in the installation folder.

Note: If you create multiple files containing different settings in a combination of the above-mentioned locations, the app will use the one in the Local folder, then (if there is none in the Local folder) the one in the Shared folder, and then (if there is none in the Local of Shared folder) the one in the Installation folder. This allow you to override the global built-in settings in the Installation folder by providing a file in the Shared folder, and even to create exceptions for some user by special settings files in their Local folders.

Mass deployment

You may find yourself needing to deploy the Corinth 3D app to many computers at once, such as to a school computer lab or multiple computers in different classrooms. Due to the fact that Corinth 3D is a Universal Windows Platform (UWP) app, you might not be able to use the tools that you are used to work with when installing Desktop Applications (e.g. from an .msi or .exe file). However, there are still multiple ways to tackle this problem, which might save your time. Which of them is the best one for you depends mainly on the software tools available to you. You can find some inspiration below.

If you use Microsoft Store for Education, you can find the Corinth 3D app there. Consult the official documentation or Microsoft Support regarding the process of mass deployment through the Microsoft Store for Education.
One of the common approaches to set up the initial configuration of multiple computers in school environments is disk imaging or cloning. One "template" machine is prepared with clean installation of an operating system and all the necessary applications, and a copy of its disk is then transfered onto other computers. The Corinth 3D app is compatible with this method. You can Sideload the app on the "template" computer and then distribute the image on other school computers. To activate Corinth 3D on each of those computers, you will need one license.

Warning: If you choose to use the License Input file (see the section about automatic activation), the license is activated during the next launch of the app, and the activation is valid for one particular computer only (it will not be valid if you transfer it to another machine). Therefore, if you wish to use this activation feature while distributing the app to multiple computers using disk imaging or cloning, you should place the License Input file to the application data folder as part of the installation process (as shown by the Corinth Installation Script sample) on the "template" computer, but not launching the app until the disk image is created. If you use a disk image containing an installation of Corinth 3D which has already been activated on another computer, you will need to re-activate the app on the target machine, e.g. by manually inserting your License Key within the app.

If you cannot use any more advanced configuration management tool, but are able to remotely connect (e.g. using Win_RDP or NetSupport School) to the relevant computers, it might be viable to install the app by connecting to the computers one by one and performing the installation from one physical location. Any means described in the Installation sections are applicable, but the use of a PowerShell script is the most advisable, if you have access to a shared network storage within your school.

Tip: It is recommended to place all the necessary files (the installation script, application package, dependencies, optionally the License Input file etc.) to a shared network storage accessible from the respective computers. That way you don't have to copy all the files to the individual computers. You can prepare a single PowerShell command to run the script, and then just connect to the computers one by one, simply opening a PowerShell window, pasting the prepared command and running it. See more about running a PowerShell script manually in the following section.

You can launch your installation script (or run the individual cmdlets one by one) manually through the PowerShell window (console).

Example (PowerShell):
.\Install-CorinthAppPackage.ps1 -PackagePath ".\Corinth3D_Sideload_x64.appx" -LicensePath ".\license_input" -UpdateStrategy "Admin" -Verbose

Note: Depending on your settings, execution of PowerShell script from various sources might be restricted or prohibited. If you have the necessary privileges, you can change the Execution Policy in PowerShell using the Set-ExecutionPolicy command, specifying the new execution policy and the scope to which it should be applied. Use the parameter -Scope Process to apply the Execution Policy to the current PowerShell session only.

Example (PowerShell):
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

If you would like to keep the settings unchanged and still run the script, you can bypass the current Execution Policy settings only for the single script launch. To do this, make sure you have the necessary privileges and run the script in the following manner (example equivalent to the previous one):

Example (PowerShell):
PowerShell.exe -ExecutionPolicy Bypass -NoProfile -File .\Install-CorinthAppPackage.ps1 -PackagePath ".\Corinth3D_Sideload_x64.appx" -LicensePath ".\license_input" -UpdateStrategy "Admin" -Verbose

Remote PowerShell commands

You can run PowerShell commands remotely on multiple computers at once, including running scripts. The script only needs to be accessible from the local computer.

Example (PowerShell):
Invoke-Command -ComputerName TEST-PC1 TEST-PC2 -FilePath .\Install-CorinthAppPackage.ps1

You can even establish a persistent session like this:

Example (PowerShell):
$s = New-PSSession -ComputerName TEST-PC1 TEST-PC2
Invoke-Command -Session $s -FilePath .\Install-CorinthAppPackage.ps1

You can find more info about running remote PowerShell commands in the official documentation.
There are various configuration management tools you can use to automatically launch a script. This section describes how to achieve this with two of the most common tools. One is focused on single-computer installation, while the other is more focused on mass deployment. Both represents a "standard Windows" approach, are widely available (on Windows computers and as a part of the Microsoft Active Directory) and are able to handle PowerShell scripts discussed in the previous sections.

You can use a Scheduled Task to execute a PowerShell script. This way, the script may run with system privileges, which is useful for automating some of the installation steps, namely automatic activation and Update Strategy setup (as discussed above).

To set up a Scheduled Task on the local computer:

  1. Open the TS window. You can do this by opening the Start menu, typing TS and pressing Enter.
  2. Select an appropriate folder in the left-side panel of the TS window, or create a new one by selecting an existing folder, right-clicking it, selecting TS_NewFolderMore, typing a name for the new folder and clicking Gen_OK.
  3. Right-click the selected folder and click TS_CreateTaskMore. A TS_CreateTask window will be opened.
  4. In the TS_General tab of the TS_CreateTask window, fill out a name and a description of the new task.
  5. Then (still on the same tab) choose the user account to be used when running the task. For example, if the script needs to be executed with system privileges, click the TS_ChangeUserMore button, then in the TS_SelectUser window, click the TS_SelectUser window type "SYSTEM" and click TS_CheckNames button, then the Gen_OK button. Back in the TS_CreateTask window, check (enable) the TS_HighestPrivileges option.
  6. Select the TS_Triggers tab, then click on TS_NewMore. A TS_NewTriggerWin window will be opened.
  7. In the TS_NewTriggerWin window, specify when the task should be performed. You can for example select to run the script at startup in the TS_BeginTask dropdown by selecting TS_Startup. Confirm your choice by clicking Gen_OK.
  8. Select the TS_Actions tab, then click on TS_NewMore. A TS_NewActionWin window will be opened.
  9. In the TS_NewActionWin window, make sure the TS_StartProg option is selected in the TS_Action dropdown. Then write "powershell.exe" into the TS_ProgramScript input. Then add the necessary arguments (particularly the path to the script itself) into the TS_AddArgs input. For example, if you are using the Corinth Installation Script located in X:\Install\Scripts\, the app package is in X:\Install\Packages\ and you wish to skip the automatic activation, then the arguments might look like this: -ExecutionPolicy Bypass -NoProfile -File 'X:\Install\Scripts\Install-CorinthAppPackage.ps1' -PackagePath 'X:\Install\Package\Corinth3D_Sideload_x64.appxbundle' -SkipLicense. After you have set the arguments, click Gen_OK.
  10. You can set additional options in the remaining tabs of the TS_CreateTask windows. After you have finished, click the Gen_OK button.
If you are using Active Directory (AD), you can use Group Policy Object (GPO) to call a PowerShell script which will install the app. The script can generally be called either during the machine/system starting up or upon the user logging on.
When a script is executed as a Startup Script, it runs in the System context, which is useful mainly to provision the app for all users.

To set up installation via the AD GPO Startup Script, you should go through the following steps:

  1. Select a suitable existing GP_Obj (GPO) or create another one and set its contents and scope.
  2. Add a Startup Script to the GPO.
  3. Configure the script's parameters.

Note: The steps above assume that the script also enables Sideloading and Data Sharing. If it does not, these features should be enabled in advance.

To add a new GP_Obj (GPO):

  1. Log in on your AD_DomainController.
  2. Open the GP_Mgmt tool on your AD_DomainController. You can do this for example from the AD_ServerManager window by clicking AD_SMTools and selecting GP_Mgmt, or from the Start menu by typing gpmc.msc and pressing Enter.
  3. Find an AD_OrgUnit (OU) which you deem appropriate to be affected by the GPO or create a new one by right-clicking a domain and selecting AD_NewOrgUnit. You can set the contents of an AD_OrgUnit via the AD_UsersAndComps tool.
  4. Right-click the AD_OrgUnit and select AD_CreateGPOMore. Alternativelly, you can create a new GPO by right-clicking the AD_GPOs item in the domain and selecting Gen_New, but then you will have to link that GPO to an OU of your choice manually.
  5. Pick a suitable name for the new GPO and click Gen_OK.
  6. You can then specify the Groups to which that GPO should apply. Select the GPO, go to the AD_GPOScope tab in the right side of the window, then use the AD_GPOScopeSecFilter panel in the lower-right side of the window.

To add a PowerShell installation script to the Startup Scripts of a GPO:

  1. Right-click the target GPO in the GP_Mgmt window and select Gen_EditMore. A AD_GPMgmtEdit window will be opened. Alternativelly, type gpme.msc in the Start menu and press Enter, then locate and open your target GPO.
  2. In the AD_GPMgmtEdit, select GP_CompConfig -> GP_Policies -> GP_WinSettings -> GP_CompScripts, then double-click the GP_Startup item in the right side of the window. The GP_StartupProps windows will be opened.
  3. Select the GP_PSScripts tab.
  4. On the GP_PSScripts tab, click Gen_AddMore. On the GP_AddScript window click Gen_BrowseMore. An Win_Explorer window will be opened.
  5. Copy all the necessary files to the directory opened by the previous step. For example, when using the Corinth Installation Script sample, Install-CorinthAppPackage.ps1, CCInstallUtils.psm1 and CCInstallUtils.psd1 must be placed there, and additional files might be also useful, such as the license_input file.
  6. Select the installation script (a file with the .ps1 extension) and click Gen_Open. The Win_Explorer window will be closed.

To set the parameters of the PowerShell Startup Script:

  1. You may need to provide the script with some parameters. This can be done in the GP_AddScript or GP_EditScript window, which was open in the previous steps or can be reached by selecting the script in the GP_PSScripts tab of the GP_Startup window, and clicking Gen_EditMore.
  2. The particular parameters must be chosen according to the desired behaviour of the script and the script itself. For example, when using the Corinth Installation Script sample without any parameters, the script assumes that the installation package and the folder structure containing its dependencies are located in the same folder as the script itself. If the packages are elsewhere, you need to specify the correct location by using the -PackagePath parameter (see more about the sample script's parameters below).
  3. Determine the correct parameters and write them to the GP_ScriptParams input of the GP_AddScript or GP_EditScript window.
  4. Click Gen_OK and then Gen_Apply on the GP_StartupProps window.
When a script is executed as a Logon Script, it runs under the user account and thus may have limited privileges. That means a Logon Script might be unable to change the related settings or install the app whatsoever, depending on the permissions assigned to a particular user. Therefore, before setting up the installation via Logon Script, you should make sure all the affected users have all necessary rights to install a UWP app for themselves and that the prerequisite settings are applied (i.e. Sideloading must be enabled and App Data Sharing should be enabled). Then you can use a Logon Script to install the app for a single user or individual users separatelly, which brings the advantage of control over which users get the app and which not, instead of installing for everyone.

Note: If you have purchased Corinth 3D license for multiple computers, each computer counts just once, regardless of the number of users to whom it is available (installed/registered). The license is therefore not a factor when deciding whether to provision the app or not.

To set up installation via the AD GPO Logon Script, you should go through following steps:

  1. Enable Sideloading on all affected computers.
  2. Enable App Data Sharing on all affected computers.
  3. Select a suitable existing GP_Obj (GPO) or create another one and set its contents and scope.
  4. Add a Logon Script to the GPO.
  5. Configure the script's parameters.

Note: Sideloading and Data Sharing should be enabled outside of the Logon Script, because the script might not have the necessary privileges to do so running under a common user account. However, it is possible to set them up using a separate Startup Script or Registry modification within the same GPO.

To add a new GP_Obj (GPO):

  1. Log in on your AD_DomainController.
  2. Open the GP_Mgmt tool on your AD_DomainController. You can do this for example from the AD_ServerManager window by clicking AD_SMTools and selecting GP_Mgmt, or from the Start menu by typing gpmc.msc and pressing Enter.
  3. Find an AD_OrgUnit (OU) which you deem appropriate to be affected by the GPO or create a new one by right-clicking a domain and selecting AD_NewOrgUnit. You can set the contents of an AD_OrgUnit via the AD_UsersAndComps tool.
  4. Right-click the AD_OrgUnit and select AD_CreateGPOMore. Alternativelly, you can create a new GPO by right-clicking the AD_GPOs item in the domain and selecting Gen_New, but then you will have to link that GPO to an OU of your choice manually.
  5. Pick a suitable name for the new GPO and click Gen_OK.
  6. You can then specify the Groups to which that GPO should apply. Select the GPO, go to the AD_GPOScope tab in the right side of the window, then use the AD_GPOScopeSecFilter panel in the lower-right side of the window.

To add a PowerShell installation script to the Startup Scripts of a GPO:

  1. Right-click the target GPO in the GP_Mgmt window and select Gen_EditMore. A AD_GPMgmtEdit window will be opened. Alternativelly, type gpme.msc in the Start menu and press Enter, then locate and open your target GPO.
  2. In the AD_GPMgmtEdit, select GP_UserConfig -> GP_Policies -> GP_WinSettings -> GP_UserScripts, then double-click the GP_Logon item in the right side of the window.
  3. Select the GP_PSScripts tab.
  4. On the GP_PSScripts tab, click Gen_AddMore. On the GP_AddScript window click Gen_BrowseMore. An Win_Explorer window will be opened.
  5. Copy all the necessary files to the directory opened by the previous step. For example, when using the Corinth Installation Script sample, Install-CorinthAppPackage.ps1, CCInstallUtils.psm1 and CCInstallUtils.psd1 must be placed there, and additional files might be also useful, such as the license_input file.
  6. Select the installation script (a file with the .ps1 extension) and click Gen_Open. The Win_Explorer window will be closed.

To set the parameters of the PowerShell Logon Script:

  1. You may need to provide the script with some parameters. This can be done in the GP_AddScript or GP_EditScript window, which was open in the previous steps or can be reached by selecting the script in the GP_PSScripts tab of the GP_Logon window, and clicking Gen_EditMore.
  2. The particular parameters must be chosen according to the desired behaviour of the script and the script itself. For example, when using the Corinth Installation Script sample without any parameters, the script assumes that the installation package and the folder structure containing its dependencies are located in the same folder as the script itself. If the packages are elsewhere, you need to specify the correct location by using the -PackagePath parameter (see more about the sample script's parameters below).
  3. Determine the correct parameters and write them to the GP_ScriptParams input of the GP_AddScript or GP_EditScript window.
  4. Click Gen_OK and then Gen_Apply on the GP_LogonProps window.

It is possible to divide the task and perform one part (e.g. global settings) with a Startup Script and a second part (e.g. adding the app to a user) with a Logon Script.

It may also be convenient to perform a crucial step by both Startup and Logon Scripts. For example, if you use a Stratup Script to enable the necessary features and to provision the app and you are not satisfied with the performance (the app is still unavailable for some users or it takes too long until it's added for them), even though the script runs successfully (the app is installed and there are no relevant errors in the EV), you may use and additional Logon Script to register the app for every user upon their logon.

Corint Installation Script sample

The Corinth Installation Script sample demonstrates some of the possibilities of a Universal Windows App (UWP) installation using PowerShell, that can be used for app deployment automation.

Warning: It is imperative that you familiarize yourself with the contents of the script and make sure that its execution is desirable for you before attempting to run it. Even then, you should first test it in a safe environment.

You are encouraged to modify the script to better fit your needs, or repurpose parts of it to create your own solution.

  • relaunch itself to try to get administrative privileges (self elevation)
  • enable Sideloading
  • enable Data Sharing
  • install an app
  • insert a License Input file into the app data
  • create a file for the Update Strategy settings
  • log its progress (which can be inspected later using EV)
  • send brief information about its launch, errors and progress (execution summary) which will be statistically processed and used to improve the future versions of the sample
  • Install-CorinthAppPackage.ps1: the main script containing execution logic
  • CC_InstallUtils.psm1: PowerShell module providing auxiliary function for controlling the related Windows features, UWP app installation, system folder path extraction etc.; you may find these useful when creating your own solution
  • CC_InstallUtils.psd1: module manifest containg some info about the module (notably its version)
The script assumes the related files placed in the following folder structure: 
                            
        Corinth\
        ├── Dependencies\
        │   └── x64\
        │       ├── Microsoft.NET.Native.Framework.1.3.appx
        │       ├── Microsoft.NET.Native.Runtime.1.4.appx
        │       └── Microsoft.VCLibs.x64.14.00.appx
        ├── Install-CorinthAppPackage.ps1
        ├── CCInstallUtils.psm1
        ├── CCInstallUtils.psd1
        ├── license_input
        └── Corinth_Sideload_x64.appxbundle
You can specify different location of the files using parameters (see below).
  • String parameters:
    • PackagePath
      • Meaning: Path to the installation package. Any depedency packages are expected to be inside a folder named "Dependencies\x64" right next to the package file.
      • Default behaviour: The script will try to find a package within its folder (appx/msix/bundle right next to the script file) if no path specified.
      • Failure action: If there is no package available on the specified path or if no path was specified and there is no single package in the default folder, the installation fails.
    • LicensePath
      • Meaning: Path to a license file which should be used to activate the app and unlock its full content during its first launch.
      • Default behaviour: Will try to use a file named "license_input" located next to this script if no path specified.
      • Failure action: If there is no file available on the specified path or if no path was specified and there is no file on the default path, the script will fail. This bahaviour can be overridden by using the SkipLicense option (app will be installed but it won't be activated).
    • UpdateStrategy
      • Meaning: Species the preferred way of user interaction when handling updates. See Update Strategy.
      • Allowed values: User, Admin or Force.
      • Default behaviour: No settings file will be created, the app will use its default settings (User).
      • Failure action: If an invalid option is specified (i.e. other than the above-mentioned three), the script fails, just as with any other unrecognized parameter.
  • Switches:
    • InstallFromWeb
      • Meaning: The script will download latest version of the installation packages from the internet and install them. Overrides PackagePath parameter.
      • Default behaviour: See PackagePath parameter.
    • RegisterOnly
      • Meaning: The script will only register the app for the current user. No further action will be taken, all other parameters (excluding Verbose, Help, PrintLog, PrintConfigReport and WhatIf) will be ignored. Presumes that the app is already installed on the computer.
      • Default behaviour: If the switch is not provided, the app will be installed and related steps will be performed.
    • SingleUser
      • Meaning: Installs the app only for the executing user.
      • Default behaviour: The app will be provisioned for all users on the computer if not otherwise specified.
    • ForceInstall
      • Meaning: Will try to re-install the app even if it is already installed.
      • Default behaviour: The installation (and all the related steps, such as certificate installation and Sideloading activation) will be skipped when there is any version of the app already available for current user.
    • SkipLicense
      • Meaning: Will not provide any license input. The app can be activated later by this script or manually within the app by specifying the license code. The LicensePath parameter will be ignored.
      • Default behaviour: The script will try to copy a license input file (either from a location specified via parameter or from a default location next to this script) to the app data, so that it can be activated. It will throw an error, if the license input is unavailable.
    • ForceLicense
      • Meaning: Will copy the license input file to the app data even if the app had been previously activated. Overrides SkipLicense.
      • Default behaviour: If the script finds data suggesting that the app has been activated in the past, it will not try to provide the app with a license input file. This is to prevent the app from excessive number of attempt to activate itself - it tries to go through the activation process each time the license input changes..
    • Verbose
      • Meaning: Enables console output. Useful when running the script manually.
      • Default behaviour: Silent execution (except for the event logging and errors).
    • Help
      • Meaning: Prints help similar to this description and exits.
    • PrintLog
      • Meaning: Prints log and exits. The same records can be accessed through the EV.
    • PrintConfigReport
      • Meaning: Prints configuration check report (i.e. Windows version, Sideloading settings, installed version of the app etc.) and exits.
    • WhatIf
      • Meaning: Prints a summary of expected steps without actually executing them.
  • The script tries to insert the License Input file into the app Installation folder. If it's not able to do so, then it uses the Local app data folder, which belongs to the user running the script. System privileges are required to write to the Installation folder. Therefore, if the script runs without them, then the app must be launched by the user, who ran the installation script, in order for the license to be activated. The activation will not be performed if the app is launched by a different user, however, if Data Sharing is enabled, then the activation is also shared and other user on the same computer will find the content unlocked after the activation is completed.
  • The main goal of the script is to allow installation for multiple users on the same machine. Creating the settings file containing the preferred Update Strategy in a user's Local app data folder would result in applying this Strategy only to that particular user (see the related section), which could be cofusing. For that reason the app never creates the settings file in the Local folder; it uses only the Shared folder or the Installation folder. System privileges are required to write to the Installation folder, and the app must have been launched at least once before the Shared folder is created (while simutaneously the Data Sharing is enabled). This means that creating the settings file as part of the installation process while running the script manually will fail, even if it's launched with the administrative privileges, because the Shared folder will not be existing yet and the Installation folder will not be writable. If you wish to use the manually-executed script to provide the settings for Update Strategy, you need to launch the app at least once before doing so, while having the Data Sharing enabled. If you use the script as a Startup Script in a GPO, the settings file will be created successfully, because the script will have the necessary privileges.
  • The script does not disable any Windows features which very enabled during its execution (Sideloading, Data Sharing).

The script logs its progress which can be later examined through the EV. You can use these records to verify the correct operation of the script or to track down an error. In the left side of the EV window, select EV_WindowsLogs -> EV_WinApplication and look for the events with the EV_Source of "Corinth Installation Script".

Every possible event has its unique number (EV_EventID). The numbers follow this system:

  • The first digit describes the type of the event:
    • 1xxx - OK - standard operation, information, success
    • 2xxx - OK - skipped operations (e.g. already valid settings; possibly due to repeated execution of the script)
    • 3xxx - warning
    • 4xxx - error
  • The second digit reffers to the step of the script:
    • x0xx - preparation phase (i.e. existing-installation check, parameter processing, event log creation, execution planning)
    • x1xx - self-elevation (relaunch), script privileges check, launch info logging
    • x2xx - installation packages acquisition (app + dependencies)
    • x3xx - certificate check
    • x4xx - Sideloading activation
    • x5xx - Data Sharing activation
    • x6xx - installation/provisioning/registration
    • x7xx - License Input and Update Strategy file placement
    • x8xx - cleanup
    • x9xx - execution summary
  • The last two digits identify the substep (e.g. checks before, during and after the step) and variant (e.g. too few vs. too many files specified)