<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Aktivierung von Microsoft Office 2024 LTSC-Lizenzen im SharedPC-Betrieb]]></title><description><![CDATA[<p dir="auto">Hallo zusammen.<br />
Wir betreiben unsere Laptops als SharedPC mit einem Gast-Account, welcher nach dem Abmelden gelöscht wird. Dies wird über die Relution Richtlinie geregelt.</p>
<p dir="auto">Mir ist nun folgendes Problem aufgefallen:</p>
<ul>
<li>
<p dir="auto">Ein MAK-Lizenzschlüssel (Multiple Activation Key) für 35 Microsoft Office 2024 LTSC-Lizenzen wies bereits <strong>105 Aktivierungen</strong> auf, obwohl die Software lediglich auf <strong>18 Laptops</strong> im Einsatz ist.</p>
</li>
<li>
<p dir="auto">Die Software wird per Windows Office Richtlinie per Konfigurations-XML auf den Laptops installiert.</p>
</li>
</ul>
<p dir="auto">Da weder ein Hardware Austausch stattgefunden hat noch eine komplette Neuinstallation vorgenommen wurde war die Verwirrung groß.</p>
<p dir="auto">Zuerst dachte ich, dass die Anmeldung der Gast-Accounts die Ursache ist. Da dies aufgrund der klassischen Aktivierungsvorgaben (MAK-Lizenzen sind schließlich an die Hardware-ID und nicht an den Benutzer gekoppelt) eigentlich ausgeschlossen schien, habe ich lange gesucht – und bin schließlich gemeinsam mit der KI zu folgender Erkenntnis gekommen:</p>
<ul>
<li>
<p dir="auto">Bei jeder Anmeldung von Gast-Accounts oder beim App-Start wurde vermutlich im Hintergrund dennoch eine Validierung bzw. erneute Anfrage angestoßen.</p>
</li>
<li>
<p dir="auto">Da der Registrierungswert UserOperations standardmäßig offen (bzw. nicht gesetzt) war, lösten diese Benutzeraktionen bei jedem Account-Wechsel im Hintergrund neue Aktivierungsanfragen an Microsoft aus, wodurch das Kontingent massiv in die Höhe kletterte.</p>
</li>
</ul>
<p dir="auto">Ziel war es folglich, diesen bisher nicht vorhandenen Registry-Eintrag festzulegen, um die Aktivierung strikt auf den Systemkontext zu beschränken.</p>
<p dir="auto">Dazu habe ich folgende Maßnahme ergriffen:</p>
<ol>
<li>
<p dir="auto"><strong>Verhinderung von User-Aktivierungen:</strong><br />
Mit Hilfe eines PowerShell Skripts wird der Registrierungswert <code>UserOperations</code> unter <code>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OfficeSoftwareProtectionPlatform</code> angelegt und auf <code>0</code> gesetzt. DDadurch können normale Benutzer und Gäste keine Aktivierungen mehr anstoßen.</p>
</li>
<li>
<p dir="auto"><strong>Direkte Initialisierung:</strong><br />
Das Skript führt im Anschluss direkt die Aktivierung (ospp.vbs /act) im Systemkontext aus, sodass man sich nicht extra einmalig manuell mit einem Admin-Account an jedem Gerät anmelden muss.</p>
</li>
<li>
<p dir="auto"><strong>Zentrale Verteilung:</strong> Das PowerShell-Skript wird zentral über eine einmalige Geräte Aktion auf den Laptops ausgerollt.</p>
</li>
</ol>
<p dir="auto">Aktuell ist dies natürlich noch reine Theorie. Und vielleicht ist das hier gerade auch totaler Blödsinn. Aber vielleicht auch nicht. Da man bei klassischen Office LTSC-Lizenzen (ohne M365-Abo) im Microsoft 365 Admin Center zwar die Lizenzanzahl, aber keinen Live-Zähler der tatsächlichen Aktivierungen einsehen kann (dafür ist meist der direkte Weg über den Microsoft-Volumenlizenzsupport oder den Reseller nötig), bleibt es spannend – aber die technische Mechanik dahinter ist logisch.</p>
<p dir="auto">Hat jemand von euch dieses Phänomen im Shared-PC-Betrieb bereits beobachten können und das Problem so oder vielleicht auch ganz anders gelöst?</p>
<p dir="auto">Viele Grüße<br />
Caro Linde</p>
]]></description><link>https://community.relution.io/topic/278/aktivierung-von-microsoft-office-2024-ltsc-lizenzen-im-sharedpc-betrieb</link><generator>RSS for Node</generator><lastBuildDate>Fri, 18 Sep 2026 09:55:19 GMT</lastBuildDate><atom:link href="https://community.relution.io/topic/278.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 17 Sep 2026 14:37:45 GMT</pubDate><ttl>60</ttl></channel></rss>