Home About Contact Latest Articles Close

Intune Remediations Transcripts

Author: Ofir Gavish

Introduction

If you like Intune Remediation scripts as much as I do – You’re gonna love this!
It's important to have logs so you’ll be able to troubleshoot your scripts, and you can also collect the logs using Intune Device Diagnostics (which I wrote an article about, detailing how to get a report for which devices have diagnostics available for download).

I wrote a PowerShell module (Start-IntuneRemediationTranscript) that handles logging for you. In this article, I’ll explain how to use it and how to add outputs to your PowerShell scripts so they will show up in the transcript logs.

Module Installation and Usage

You can install the module from the PowerShell Gallery (Start-IntuneRemediationTranscript) using:

Install-Module -Name Start-IntuneRemediationTranscript

Features

To start a transcript with the default settings:

Start-IntuneRemediationTranscript -LogName "MyIntuneLog"

Or, to specify a custom log directory and size threshold:

Start-IntuneRemediationTranscript -LogName "CustomLog" -LogDirectory "C:\\CustomLogs" -SizeThresholdMB 10

Pre-transcripts error logs are written to:

C:\ProgramData\ErrorLogs\Esi-Transcript_ErrorLog.txt

Transcripts are logged to:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\YourLogName.log

So you can collect the logs using Intune Device Diagnostics

To stop the transcript:

Start-IntuneRemediationTranscript -Stop

Integrating the Module into Your Scripts

Always start your Intune remediation scripts with these lines:

if (Get-Module -Name Start-IntuneRemediationTranscript)
{
    try 
    {
        Install-Module -Name Start-IntuneRemediationTranscript
    } 
    catch 
    {
        Write-Host "Error installing module: $_"
    }
}
Start-IntuneRemediationTranscript -LogName ScriptName

This will check if the module is installed, install it if not, and then start the transcript. The transcript records all outputs in a PowerShell session by default. To make debugging easier, use Write-Host to specify what output belongs to what command.

Here’s an example using a System Restore script:

try
{
    # Check System Restore status using registry keys
    $restoreKey = Get-ItemProperty -Path "HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\SystemRestore"

    # Check for existing restore points
    $restorePoints = Get-ComputerRestorePoint

    $today = Get-Date

    # Input string
    $string = $restorePoints.CreationTime

    # Extract the datetime part without milliseconds and timezone offset
    $datetimePart = $string.Substring(0, 14)

    # Convert the datetime part to a DateTime object
    $datetime = [datetime]::ParseExact($datetimePart, "yyyyMMddHHmmss", $null)

    # Format the datetime object to the desired format
    $formattedDatetime = $datetime.ToString("MM/dd/yyyy h:mm:ss tt")

    $timespan = New-TimeSpan $formattedDatetime $today

    # If System Restore is disabled or no restore points exist, enable it
    if ($restorekey.RPSessionInterval -eq 0 -or $restorePoints.Count -eq 0 -or $timespan.Days -ge 30) 
    {
      Write-Host "System Restore is disabled or there are no restore points."
      Write-Host  "Enabling System Restore"
      Enable-ComputerRestore -Drive "C:\\"
      if ($restorePoints.Count -eq 0 -or $timespan.Days -ge 30)
      {
        Write-Host "Creating a Restore Point"
        Checkpoint-Computer -Description "RemediationSysRestorePoint" -RestorePointType MODIFY_SETTINGS
      }
    }
    else 
    {
      Write-Host "restore points count: $($restorePoints.Count) , restore points creation time: $($restorePoints.CreationTime)"
      Write-Host "System Restore is already enabled with existing restore points."
      Exit 0
    }
}
catch
{
    Exit 1
}
Exit 0

Using Write-Host ensures you can analyze and troubleshoot effectively, as outputs are visible both locally and in Intune by adding the columns:.

Intune Remediations Status
Intune Remediations Status

Add these and click Apply at the buttom, then you'll be able to see it in Intune:

Intune Remediations Status

Here’s another example for updating templates:

try {
    # Remove template files if they exist
    Remove-Item "$env:USERPROFILE\AppData\Roaming\Microsoft\Templates\Normal.dotm" -ErrorAction SilentlyContinue
    Remove-Item "$env:USERPROFILE\AppData\Roaming\Microsoft\Templates\blank.potx" -ErrorAction SilentlyContinue
} catch {
    Write-Host "Template files not found or could not be removed."
}

This is part of a larger script for updating default Word and PowerPoint templates, which will be covered in a future post.

Conclusion

By incorporating the Start-IntuneRemediationTranscript module into your scripts, you can simplify logging and troubleshooting, saving time and effort. Detailed logging not only provides better insights into script behavior but also allows for more robust troubleshooting within Intune environments.

With proper integration and thorough testing, this approach can significantly enhance the reliability of your remediation scripts. Don’t forget to adapt the examples above to suit your needs and always validate changes before full-scale deployment. Happy scripting!