© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2022
O. HeaumeUnderstanding Microsoft Intunehttps://doi.org/10.1007/978-1-4842-8850-4_8

8. Deployment Template

Owen Heaume1  
(1)
West Sussex, UK
 

Using a deployment template can greatly speed up your application deployments and they offer many advantages over writing a separate script each time you wish to deploy an application. Once you have written a template and ironed out all the bugs then you end up with something that offers advanced functionality and is repeatable and reliable.

With a template, the hard work has already been done and you just have to “fill in the blanks.”

In this chapter, you will learn all about the basic deployment template I wrote, and how to use it.

What It Does

This template can achieve the following:

  • It can install based on Microsoft Office “bitness.”

  • It can install based on operating system architecture.

  • It can process pre-installation tasks.

  • It can process post-installation tasks.

  • The installation includes a log file.

The Template

To make sense of this chapter, it is best to open Listing 8-1 in the PowerShell ISE and follow along. If you do not want to (or cannot), it has been reproduced here in the book for convenience although the line wrapping and lack of coloration will make it less readable.
Function Invoke-PreInstallation {
    # Anything you do here will occur **before** the ↩ installation...
    # Perhaps copy some files, register some DLLs or ↩
    anything else you can think of!
}
function Invoke-PostInstallation {
    # Anything you do here will occur **after** the ↩ installation...
    # Perhaps copy some files, register some DLLs or ↩
    anything else you can think of!
}
Function Invoke-ApplicationInstall {
    # Installs applications depending on office bitness or ↩
    os bitness
    # To install using Office bitness, use the switch ↩
    -InstallBasedOnOfficeBitness
    # To install based on OS architecture ↩
    (32-bit or 64-bit) do not use the switch
    [CmdletBinding()]
    Param (
        [Switch]
        $InstallBasedOnOfficeBitness
    )
    Begin {
        $WorkingDir = Get-Location
        $LoggedInUser = (Get-CimInstance -ClassName ↩ CIM_ComputerSystem).username | Split-Path -Leaf
        $OSArchitecture = (Get-CimInstance -ClassName ↩ CIM_OperatingSystem).OSArchitecture $OfficePaths = ↩
        @('HKLM:SoftwareMicrosoftOffice','HKLM:↩
SoftwareWOW6432NodeMicrosoftOffice')
        $OfficeVersions = @('14.0', '15.0', '16.0')
        Push-Location
        foreach ($Path in $OfficePaths) {
            foreach ($Version in $OfficeVersions) {
                try {
                    Set-Location "$Path$VersionOutlook" ↩
-ea stop -ev x
                    $Bitness = Get-ItemPropertyValue ↩
-Name "Bitness" -ea stop -ev x
                    switch ($bitness) {
                        'x86' {$Is32Bit = $True}
                        'x64' {$Is32Bit = $false}
                    }
                    break
                } catch {
                    $Is32Bit = 'Unknown'
                }
            }
            if ($Is32Bit -eq $true -or $Is32Bit -eq $false) {break}
        }
        $Obj = [pscustomobject]@{
            CurrentUser   = $LoggedInUser
            OfficeIs32Bit = $Is32Bit
            OSis64Bit     = if ($OSArchitecture -eq ↩
'64-Bit') {$True} else {$false}
        }
        Pop-Location
    }
    Process {
        # --- PRE-INSTALL SECTION ---
        Invoke-PreInstallation
        # --- END PRE-INSTALL ---
        if ($InstallBasedOnOfficeBitness) {
            # Install the application depending on if ↩ Microsoft Office is 64bit or 32bit or not installed
            # $True = Office is 32bit - Use this part to ↩ install 32bit applications
            # False = Office is 64bit - Use this part to ↩ install 64bit applications
            # Unknown = Office may not be installed.
            switch ($Obj.OfficeIs32Bit) {
                $true {"Install a 32-bit application here"}
                $false {"Install a 64-bit application here"}
                'Unknown' {"Office not detected – ↩
do what you want here"}
            }
        }
        else {
            # Installs a 64bt or 32bit application ↩
depending on the OS Architecture.
            # $True = The OS Architecture is 64-bit ↩
- Use this part to install the 64-bit application.
            # default = The OS is 32-Bit ↩
- Use this part to install the 32-bit application.
            switch ($obj.OSIs64Bit) {
                $True {start-process -FilePath ↩ "$ENV:SystemRootSystem32msiexec.exe" ↩
-ArgumentList "/i ""$workingDirYour64-BitMSI"" ↩
/qn" -NoNewWindow -Wait}
                default {start-process -FilePath ↩ "$ENV:SystemRootSystem32msiexec.exe" ↩
-ArgumentList "/i ""$workingDirYour32BitMSI"" ↩
/qn" -NoNewWindow -Wait}
            }
        }
        # --- POST-INSTALL SECTION ---
        Invoke-PostInstallation
        # --- END POST-INSTALL SECTION
    }
    End {
        # Write what the discovered object values are to a log.
        # This may help in troubleshooting.
        # Feel free to expand this section to include ↩
anything else that you want logged.
        "Logged In User: $($Obj.CurrentUser)" ↩
| out-file -FilePath ".Invoke-ApplicationInstall.log" ↩
-ErrorAction SilentlyContinue
        "Office Version is 32Bit: $($Obj.OfficeIs32Bit)" ↩
| out-file -FilePath ".Invoke-ApplicationInstall.log" ↩
-Append -ErrorAction SilentlyContinue
        "Operating System is 64Bit: $($Obj.OSis64Bit)" ↩
| out-file -FilePath ".Invoke-ApplicationInstall.log" ↩
-Append -ErrorAction SilentlyContinue
    }
}
#Script entry point
Invoke-ApplicationInstall
Listing 8-1

The full PowerShell template

The Template – Explained

When you examine the PowerShell code for this template there will be two mindsets: those with little to no PowerShell experience will be thinking it looks complex, and those with some PowerShell experience will be thinking, “Is that it?” And really, the mindset should be of the latter because the reality is, that this is a simple template.

The template consists of three functions and one switch. Let us start with an overview of each one to better understand how it works.

Function 1: Invoke-PreInstallation

Any code you place in this section will be executed before (or pre) the application is deployed. Any additional code you add needs to be between the curly braces. ({ and })

Examples of code I have placed in these sections are usually copying files to a specific location on an endpoint, but you could do anything that PowerShell allows. Just understand that it will execute before Function 3.

Note

You should understand that PowerShell is a script and not a compiled language. Scripts are executed from top to bottom, line-by-line, and therefore if a function has not yet been defined first, then it cannot be called later in the script. Function 1 and Function 2 are called by Function 3, and so must be defined in the script before Function 3 so that they are ready to be used.

Function 2: Invoke-PostInstallation

Any code you place in this section will be executed after (or post) the application is deployed. Any additional code you add needs to be between the curly braces. ({ and })

Examples of code I have placed in these sections are usually along the lines of registering DLLs, registry modifications to customize the application that was just installed, or copying/replacing application INI files.

Once again, you are only limited by the constraints of PowerShell. Code placed in this section will occur after Function 3.

Function 3: Invoke-ApplicationInstall

This function is the meat-and-potatoes of the template. Here you can customize the install based on Microsoft Office “bitness,” or operating system architecture.

Begin Block

Ignoring the switch for the moment, the code in the Begin { } block starts by setting the current location to the location that the script is being executed from and then populates various variables such as the logged-in user, the operating system architecture, and registry paths where one might expect to find Microsoft Office information if it were installed. The information stored in these variables will be used later.

The current location is pushed to the location stack via the Push-Location cmdlet and then a nested foreach loop is used to iterate through the Microsoft Office registry locations where an attempt is made to set the location using the Set-Location cmdlet, to the “Outlook” registry subkey. If the location can be set, then the “bitness” value is obtained, and the variable $Is32Bit is set to either $true or $false, depending on the value.

Figure 8-1 shows one of the registry locations being tested.

A screenshot of a window titled registry editor. A file titled outlook is open in which 2 files with name, type, and data are listed.

Figure 8-1

This Office location exists, and you can see that the Office bitness is x64. $Is32Bit is set to $False

Next, a custom PowerShell object is created to store the information obtained thus far and it will be accessed later. You do not need to use a custom object here; standard variables would work just as well, it is just my preferred method. You can read all about custom objects in the Microsoft documentation.1

Finally, because the working location was potentially changed to a registry location, the working location is set back to the script execution location using the cmdlet Pop-Location.

Process Block

The process block is where the application installation will take place.

Before that can happen, Function 1 is called: Invoke-PreInstallation. This will ensure that any pre-install tasks are carried out before the program installation occurs.

If the application is to be deployed based on Office “bitness,” then that occurs next. If the application must be installed only if Microsoft Office has been detected and is 32-bit, then your application install command line must be entered in between the curly braces of the $true statement. (Replacing the text, “Install a 32-bit application here”)

If the application must be installed only if the detected Office version is 64-bit, then the application install command line must be entered between the curly braces of the $false statement.

If you wish to do something if Office was not detected, then add code between the curly braces of the Unknown statement.

Figure 8-2 is a snippet taken from the full template code in Listing 8-1 that shows the locations where you would enter the application installation command, which could be an MSI or a Setup.exe, for this scenario.

A four-line code for the location of the application install command.

Figure 8-2

Lines 73, 74, and 75 show the locations where you should add the application install commands for Office “bitness.” Although you can add command lines to all three places, you only need to add them to the ones you wish to action

Installing the application based on detected Operating System architecture is tackled next.

If the switch to install based on Office “bitness” was not used, then the application will default to installing based on if the operating system architecture is a 32-bit or 64-bit installation of Microsoft Windows.

If you wish to only install the application if the detected architecture is 64-bit, then the application installation command line must be entered between the curly braces of the $true statement. Likewise, enter the installation command line between the curly braces of the default statement to only install the application if the detected architecture is 32-bit.

Figure 8-3 is a snippet taken from the full template code in Listing 8-1 that shows the locations where you would enter the application installation command for this scenario.

A three-line code of the location of the application install command.

Figure 8-3

Lines 84 and 85 show the locations where you should add the application install commands for installing based on operating system architecture. Although you can add command lines to both places, you only need to add them to the ones you wish to action

Once the application has been installed, a call to Function 2 is made: Invoke-PostInstallation. This will execute any desired code after the application installation has taken place.

End Block

The end block is the last code section to execute in Function 2 and it adds basic logging. It will write a log file containing the current logged-in username, the detected Microsoft Office “bitness” and finally whether the installed operating system is 32-bit or 64-bit.

The log file is named, Invoke-ApplicationInstall.log, and can be found in the Windows emp directory.

The Switch

The template contains a single switch, $InstallBasedOnOfficeBitness. This is defined near the top of Function 3 and it is optional to use when calling the script. If it is used, then the application will only install based on the detected Office “bitness.” If the switch is not used, then the application will install based on the detected operating system architecture.

Figure 8-4 shows the location of the switch definition in the full template code from Listing 8-1.

A code of the location of the switch.

Figure 8-4

Line 21 is where the switch has been defined

You can read all about switches from the built-in PowerShell help, and by now you should be very familiar with the help about_ commands:
 help about_switch

The Template Command Line

This template uses a script entry point, and the final line of code in the template calls the main function (Function 3) to set the whole process running:
Invoke-ApplicationInstall
The installation command line to use within the Intune portal when creating an application using this template is shown in Listing 8-2.
"C:WindowsSysnativeWindowsPowerShellv1.0PowerShell.exe" ↩
-noprofile -executionpolicy bypass -file ↩
.Invoke-ApplicationInstall.ps1
Listing 8-2

The template installation command for Intune

This template has been written as a demonstration of a simple working example. You are free to use this as-is, modify it to suit your requirements, or use it as the basis of a template you write.

It was written to demonstrate basic template structures and concepts and has room for improvement in many areas. For example, you can add more extensive logging, encapsulate the various parameters as functions (such as deploying based on Office “bitness”), which can then be called directly from the installation command line instead of using a script entry point, or perhaps all your endpoints are 64-bit, and you can remove some of the redundant system architecture code.

The world is your oyster, and you should now feel confident to perform some of these modification tasks yourself or even write a template of your own from scratch.

Summary

In this chapter, you learned why you might use a template and examined the code of a ready-to-use example template. You learned how each part of the example template was constructed, and how to use it for your deployments.

In the next chapter, you will learn about preparing the application so that it may be imported into Intune for deployment.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.117.234.225