Verknüpfungen mit Intune bereitstellen: Deine Optionen

Verknüpfungen mit Intune bereitzustellen klingt banal. In der Praxis ist es eines dieser Themen, bei denen viele kleine Details entscheiden, ob es zuverlässig funktioniert oder nicht.

Am liebsten hätten wir noch immer eine einfache Dateikopier-Funktion, so wie wir sie mit Group Policy Preferences kannten. Leider ist das mit Intune keine Option. Also müssen wir mit den Werkzeugen arbeiten, die wir haben.

In diesem Beitrag zeige ich dir die realistischen Optionen, um Verknüpfungen mit Intune zu verteilen, basierend auf dem, was ich in Kundenumgebungen einsetze. Ich fokussiere mich dabei auf Datei-Verknüpfungen, Startmenü-Links und die Abwägung zwischen Plattformskripts, Remediations und Win32-Apps.

Was wir eigentlich mit Verknüpfungen meinen

Bevor wir über die Bereitstellungsmethoden sprechen, lohnt es sich, genau zu sein.

Es gibt zwei gängige Verknüpfungstypen bei Intune-Szenarien.

Datei-Verknüpfungen

Das sind klassische .lnk-Dateien.

Typische Anwendungsfälle sind:

• Desktop-Verknüpfungen zu Applikationen oder Freigaben
• Startmenü-Einträge, die auf ausführbare Dateien zeigen
• Verknüpfungen zu UNC-Pfaden wie Dateiservern

Startmenü-Pins

Wenn ich von Startmenü-Links in Intune spreche, meine ich eigentlich Startmenü-Pins.

Ein Startmenü-Pin ist selbst keine Verknüpfung. Er verweist immer auf eine bestehende Applikation oder Datei-Verknüpfung.

Du kannst anpinnen:

• Applikationen
• Ausführbare Dateien
• Datei-/Ordner-Verknüpfungen

Eine wichtige Einschränkung aus der Praxis.

Möchtest du einen UNC-Pfad oder einen Dateisystem-Speicherort anpinnen, musst du zuerst eine .lnk-Datei erstellen, die auf diesen Pfad zeigt. Der Startmenü-Pin verweist dann auf diese Verknüpfung.

Das heisst, die Datei-Verknüpfung ist immer der erste Schritt. Der Pin ist nur eine visuelle Ebene darüber.

Die eigentliche Herausforderung ist also nicht das Anpinnen. Die Herausforderung ist, die zugrunde liegende Verknüpfung zuverlässig mit Intune zu verteilen.

Option 1: Plattformskripts

Plattformskripts sind oft die erste Wahl. Sie sind schnell und flexibel.

So funktioniert es

Ich verwende ein PowerShell-Skript, das:

1. Die Verknüpfung erstellt
2. Zielpfad, Argumente und Icon setzt
3. Sie auf dem Desktop oder im Startmenü platziert

Meistens läuft das im SYSTEM-Kontext. Du kannst Verknüpfungen zwar auch im Benutzerkontext verteilen, dann kann der Benutzer die Verknüpfung aber auch wieder löschen.

Als Nächstes zeige ich dir ein paar Beispielskripts zum Einstieg.

Skript 1: Einfache Verknüpfung

Das ist die Basisvariante. Sie eignet sich perfekt für lokale Ziele.

$ShortcutPath = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\My Application.lnk"
$TargetPath   = "C:\Program\My Application.exe"

$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut($ShortcutPath)
$Shortcut.TargetPath  = $TargetPath
$Shortcut.Save()

Skript 2: Verknüpfung mit eigenem Icon (Base64)

Das nutze ich, wenn ich keine Icon-Datei auf einer Freigabe ablegen oder als separates Asset paketieren möchte.

Ich bette das Icon als Base64 ein und schreibe es während der Ausführung auf die Festplatte.

# Variables
$ShortcutPath = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\My Application.lnk"
$TargetPath   = "C:\Program\My Application.exe"
$Base64Icon   = "iVBORw0KGgoAAAANSUhEUgAAADIAAAAyCAMAAAAp4XiDAAAAqFBMVEUAAAD////////////6+vr+/v78/Pz+/v739/f////9/f36+vr8/Pz+/v7+/v75+fn+/v7+/v79/f39/f36+vr9/f38/Pz6+vr+/v7+/v7+/v7+/v79/f39/f39/f39/f39/f38/Pz7+/v6+vr+/v79/f39/f38/Pz7+/v7+/v////9/f39/f39/f39/f38/Pz+/v79/f38/Pz7+/v6+vr9/f37+/v///+jDSucAAAAN3RSTlMA/e3qMN4c+gZoliB44dgM9PeGWxB9SRjTzb+7tatzbmBCKxXmmWlPNSbwn5KOZTnFslY7JHk/jkR60wAAAhtJREFUSMe1ltmWojAQQKtADI0jKIgbKu772vZM/v/PpgfKbMI5mYe+b6mcGyqhUgCC1vw07CA3wZzmYyzHH0Ac4pAhr8A7QMFgyDXFv3rIK8ELlFyZpvTOXV6Duy+NaMxVJdpgnYFTv1T6HU1JGa+js6PMp6gqC5fXMo5KZe9yRYkeWGuwK5RcUCqUJQ2dtqfSzgZ0wlm74DsWJgCByHKYN1pNjRWU+M3WP4rZCFajl3FfghVyY84CLNl1SXn4loYshBhs2b6U/P+VmbWSvJSNtbI48pJh01b58kjB2PbI/Imo2rhl6eSy4rzpJiA2O5p+BsE5TRqRllnIJUjwTl9clG+YO56pKfxG/s6Elr05r8XCWU8oq/G7wxKaPKOMTWTd3rw3ZURlf2irWQ9vwumbLQlnZtLkKM8xcvO+6DaOjKUecj+D1MOKfjdn5h63IDnMsjXDEtHvMgoomxxodXDob38VJD6dZV4M01MoJPYJdrREB8YTWOJvUB6/Jcs2KeuG9WOmpFDx2RBTZt3Pn1QCFJ8PS3r3V1N92ipJl5TQ9rYvQnH3fOg1NKgzaeF9/7JG5VrMXUdlTkp6lLGj8kewXgJ80FDPtEmJmGAAQjHa/xarFW8pFKOAeuOab/ocDAVP+nfKpJv6pnJcqD8GJujmPgjF6HdPp8JgGS2oKiyR9aSD6GQJNZfivbglzn1AJzyiEMXdcJL+kX38L5HQzx19r4jUAAAAAElFTkSuQmCC" # https://codebeautify.org/png-to-base64-converter

# Write icon to disk next to the shortcut
$IconPath = [System.IO.Path]::ChangeExtension($ShortcutPath, ".ico")
[System.IO.File]::WriteAllBytes($IconPath, [Convert]::FromBase64String($Base64Icon))

# Create shortcut
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut($ShortcutPath)
$Shortcut.TargetPath   = $TargetPath
$Shortcut.IconLocation = "$IconPath,0"
$Shortcut.Save()

Skript 3: UNC-Verknüpfung, die im SYSTEM-Kontext funktioniert (mit Logging)

An UNC-Pfaden scheitern viele Verknüpfungen. Das Ziel ist während der Verteilung oft nicht erreichbar. Das kommt im SYSTEM-Kontext häufig vor.

In diesem Fall erstelle ich eine Verknüpfung, die den Explorer startet und den UNC-Pfad als Argument übergibt. Zusätzlich füge ich ein Transcript für die Fehlersuche hinzu.

$ScriptName = "Windows_Script_ShortCut-DEMO"
Start-Transcript -Path "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\$ScriptName.log" -Force

# Variables
$ShortcutPath = "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\DEMO.lnk"
$TargetUNC    = "\\file.sclouod.es\DEMO"
$Base64Icon   = "iVBORw0KGgoAAAANSUhEUgAAADIAAAAyCAMAAAAp4XiDAAAAqFBMVEUAAAD////////////6+vr+/v78/Pz+/v739/f////9/f36+vr8/Pz+/v7+/v75+fn+/v7+/v79/f39/f36+vr9/f38/Pz6+vr+/v7+/v7+/v7+/v79/f39/f39/f39/f39/f38/Pz7+/v6+vr+/v79/f39/f38/Pz7+/v7+/v////9/f39/f39/f39/f38/Pz+/v79/f38/Pz7+/v6+vr9/f37+/v///+jDSucAAAAN3RSTlMA/e3qMN4c+gZoliB44dgM9PeGWxB9SRjTzb+7tatzbmBCKxXmmWlPNSbwn5KOZTnFslY7JHk/jkR60wAAAhtJREFUSMe1ltmWojAQQKtADI0jKIgbKu772vZM/v/PpgfKbMI5mYe+b6mcGyqhUgCC1vw07CA3wZzmYyzHH0Ac4pAhr8A7QMFgyDXFv3rIK8ELlFyZpvTOXV6Duy+NaMxVJdpgnYFTv1T6HU1JGa+js6PMp6gqC5fXMo5KZe9yRYkeWGuwK5RcUCqUJQ2dtqfSzgZ0wlm74DsWJgCByHKYN1pNjRWU+M3WP4rZCFajl3FfghVyY84CLNl1SXn4loYshBhs2b6U/P+VmbWSvJSNtbI48pJh01b58kjB2PbI/Imo2rhl6eSy4rzpJiA2O5p+BsE5TRqRllnIJUjwTl9clG+YO56pKfxG/s6Elr05r8XCWU8oq/G7wxKaPKOMTWTd3rw3ZURlf2irWQ9vwumbLQlnZtLkKM8xcvO+6DaOjKUecj+D1MOKfjdn5h63IDnMsjXDEtHvMgoomxxodXDob38VJD6dZV4M01MoJPYJdrREB8YTWOJvUB6/Jcs2KeuG9WOmpFDx2RBTZt3Pn1QCFJ8PS3r3V1N92ipJl5TQ9rYvQnH3fOg1NKgzaeF9/7JG5VrMXUdlTkp6lLGj8kewXgJ80FDPtEmJmGAAQjHa/xarFW8pFKOAeuOab/ocDAVP+nfKpJv6pnJcqD8GJujmPgjF6HdPp8JgGS2oKiyR9aSD6GQJNZfivbglzn1AJzyiEMXdcJL+kX38L5HQzx19r4jUAAAAAElFTkSuQmCC" # https://codebeautify.org/png-to-base64-converter

# Ensure Start Menu folder exists
$ShortcutDir = Split-Path -Path $ShortcutPath -Parent
if (-not (Test-Path $ShortcutDir)) {
    New-Item -Path $ShortcutDir -ItemType Directory -Force | Out-Null
}

# Write icon to disk next to the shortcut
$IconPath = [System.IO.Path]::ChangeExtension($ShortcutPath, ".ico")
[System.IO.File]::WriteAllBytes($IconPath, [Convert]::FromBase64String($Base64Icon))

# Create shortcut
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut($ShortcutPath)

# Always use Explorer as target, UNC as argument
$Shortcut.TargetPath   = "$env:WINDIR\explorer.exe"
$Shortcut.Arguments    = "`"$TargetUNC`""
$Shortcut.WorkingDirectory = $env:WINDIR
$Shortcut.WindowStyle      = 1
$Shortcut.Description      = "Schulungsunterlagen"
$Shortcut.IconLocation = "$IconPath,0"

$Shortcut.Save()

Stop-Transcript

Vor- und Nachteile

Vorteil	Nachteil
Schnell umgesetzt	Keine native Erkennung
Sehr flexibel	Keine Versionierung
Kein Paketieren nötig	Läuft nur einmal, gelöscht kommt sie nicht zurück

Hinweis zu Base64-Icons

Um den Base64-Wert zu erzeugen, wandle ich ein kleines PNG mit https://codebeautify.org/png-to-base64-converter um.

Halte die Icon-Datei klein. Rund 1 KB funktioniert gut. Sonst wird der Base64-String riesig und das Skript unnötig gross.

Option 2: Proactive Remediation

Proactive Remediations sind meine bevorzugte Option für benutzerseitige Verknüpfungen (im Benutzerkontext).

So funktioniert es

Ich nutze ein Detection-Skript, das prüft, ob die Verknüpfung existiert. Schlägt die Detection fehl, erstellt oder repariert das Remediation-Skript die Verknüpfung. Das Remediation-Skript ist dasselbe wie das Plattformskript oben.

Beispiel für die Detection

Test-Path "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Company Share.lnk" 

Vor- und Nachteile

Vorteil	Nachteil
Selbstheilend	Benötigt eine Proactive-Remediations-Lizenz
Saubere Erkennungslogik	Etwas mehr Aufwand bei der Einrichtung
Automatische Neuerstellung

Option 3: Win32-App

Win32-Apps geben dir die meiste Struktur und Kontrolle. Sie eignen sich ideal, wenn das Lifecycle-Management wichtig ist.

Hier gibt es zwei sinnvolle Varianten.

Win32-Variante A: Skriptbasierte Win32-App

Dieser Ansatz nutzt dieselbe PowerShell-Logik wie die Plattformskripts, verpackt sie aber in eine Win32-App. Hast du keine Enterprise-Lizenzen für Remediations, ist das eine gute Alternative.

# past Platform script from above here

# Detection / Versioing Registry Key
$Path = "HKCU:\Software\scloud\Shortcut-Company Share"
$Key = "Version" 
$KeyFormat = "dword"
$Value = "1.0"

if(!(Test-Path $Path)){New-Item -Path $Path -Force}
if(!$Key){Set-Item -Path $Path -Value $Value
}else{Set-ItemProperty -Path $Path -Name $Key -Value $Value -Type $KeyFormat}

Vor- und Nachteile

Vorteil	Nachteil
Erkennung und Versionierung	Zusätzlicher Paketierungsaufwand
Installation und Deinstallation möglich	Etwas mehr Komplexität
Vorhersehbarer Lifecycle

Win32-Variante B: Die fertigen Verknüpfungsdateien verteilen

Diese Option wird oft unterschätzt. Manchmal ist der einfachste Ansatz auch der beste.

Hier erstelle ich die .lnk-Dateien im Voraus, paketiere sie und kopiere sie während der Installation an den richtigen Ort.

Vor- und Nachteile

Vorteil	Nachteil
Extrem einfach	Nicht dynamisch
Kein Scripting zur Laufzeit	Änderungen erfordern eine neue Paketierung
Sehr stabil

Meine Empfehlung

Wenn ich es vereinfachen müsste:

• Einmalige Verknüpfung: Plattformskript
• Benutzer-Verknüpfung: Proactive Remediation
• Verwaltetes Lifecycle oder Sammlungen: Win32-App

Dieser Ansatz skaliert gut und bleibt wartbar.

Fazit

Verknüpfungen mit Intune bereitzustellen ist nicht schwierig. Es braucht nur die richtige Funktion für den jeweiligen Fall.

Ein nativer Dateikopier-Mechanismus wie bei Group Policy Preferences wäre schön. Da es den nicht gibt, nutzen wir die Werkzeuge, die Intune uns bietet, und planen entsprechend.

Die meisten Probleme, die ich sehe, liegen nicht an Intune selbst. Sie entstehen durch kleine Design-Fehler:

• Benutzerkontext, wo eigentlich SYSTEM nötig wäre
• Netzwerkpfade für Icons referenzieren
• Fehlende Erkennungslogik
• Desktop- und Startmenü-Pfade vermsichen

Sobald du diese Stolpersteine und die Abwägungen jeder Option verstehst, werden Verknüpfungs-Deployments wieder langweilig. Und langweilig ist gut.