Kategorie-Archiv: Allgemein

Windows 10 VPN Einwahl bricht ab, Ereignisprotokoll zeigt Fehler 720

Veröffentlicht am von — Keine Kommentare ↓

Nach einigen Windows-Updates mag so manche Windows 10 Installation plötzlich keine VPN-Verbindungen mehr herstellen. Das passiert häufig wenn es eine weitere Software-Adapterlösung auf der Maschine gibt (NordVPN, TeamViewer VPN Adapter …).

Bei dem Fehler 720 bei VPN-Verbindungen unter Windows 10 gibt es aber diese beiden Lösungen, die fast immer helfen.

Die offizielle Fehlermeldungen-Liste von Microsoft hilft da leider auch nicht weiter und sagt nur dise Meldung bedeutet „Keine PPP-Kontrollprotokolle konfiguriert“ (oder in Englisch: „No PPP control protocols configured“). Zum Schmunzeln: Der zugehörige Artikel ist auch noch von der KI übersetzt und nennt sich selbst „Fehler 720: keine PPP steuern konfiguriert“. Das wird es sein 🙂

Möglichkeit 1: WAN-Miniports neuinstallieren

Im Gerätemanager sind unter dem Netzwerkadapter für jedes Verbindungsprotokoll einzeln die WAN Miniports aufgeführt (WAN Miniport IKEv2, WAN Miniport IP, …).

Diese Miniports einfach ALLE entfernen (Rechte MT, dann „deinstallieren“ wählen) und danach den PC neu starten. Nach dem reboot funktioniert das VPN in der Regel sofort wieder wie vorher. In seltenen Fällen mussten wir die VPN-Verbindung neu erstellen bevor es wieder lief.

Möglichkeit 2: TCP/IP komplett zurücksetzen

Achtung, nach diesem Schritt sind keine manuellen IP-Konfigurationen mehr da, man muss seine Adapter alle neu konfigurieren!

In einer „Als Administrator“ geöffneten Shell tippt man:

C:\> netsh int ip reset

Das setzt alle TCP/IP-Bindungen komplett zurück und erstellt neue IDs für die Adapterverbindung.

VMWare vCenter Appliance (VCSA) hängt beim booten bei "Starting VMware Log Browser"
Office 2010 aus Office365 sagt "Produkt nicht aktiviert"
Veeam "Unable to update SQL backupset for instance SQLEXPRESS : Code = 0x80040e09 Code meaning = IDi...

vmWare ESXi Host Warnung „esx.problem.hyperthreading.unmitigated“ (ESXi 6.5/6.7)

Veröffentlicht am von — Keine Kommentare ↓
esx.problem.hyperthreading.unmitigated

Aktuelle ESXi Server beschweren sich mit einer Warnung über CPUs mit Microcode, die anfällig für Angriffe wie Meltdown, Lazy FP state restore und/oder die L1 Terminal Fault sind. Einige AMD und Intel Prozessoren können über so einen side-channel Angriff Daten lesbar machen, die nicht lesbar sein sollten.

Bevor die Warnung unterdrückt wird, lohnt abe ein Blick in die Mitigation und vor allem auch die performance impacts. In privaten Cluster Setups ist die Gefahr eines solchen Angriffs vermutlich auch nicht so hoch, wie in öffentlichen Wolken.

Lösung

Da die Mitigations dazu ziemlich viel CPU-Performance fressen, bleiben die Schutzfunktionen wie der „Side-Channel-Aware Scheduler“ in privaten und geschlossenen Clustern oft ausgeschaltet. Trotzdem will man die Warnung natürlich loswerden 🙂

Möglichkeit 1 – Warnung unterdrücken

  1. vSphere GUI (vCenter) öffnen, den betroffenen Host auswählen
  2. Konfigurieren > Erweiterte Systemeinstellungen > Bearbeiten
  3. „UserVars.SuppressHyperthreadWarning“ auf „1“ stellen
SuppressHyperthreadWarning

Möglichkeit 2 – „Side-Channel-Aware Scheduler“ einschalten

  1. ESXi Hostclient (nicht im vCenter) öffnen
  2. Konfiguration > Erweiterte Einstellungen > Bearbeiten
  3. „VMkernel.Boot.hyperthreadingMitigation“ auf „true“ stellen
  4. Host neu starten

Es empfielt sich vor diesem Schritt das zugehörige Support-Dokument zu lesen. Hier sind die Vorbereitungen für diesen Schritt und die möglichen Auswirkungen davon genauer beschrieben.

Aktivierung des 'sa' Benutzers auf SQL Server Express Edition
Windows Server 2019 RRAS startet nicht (8007042a) - NPS Event 4405
VMWare Converter braucht Ewigkeiten für die Virtualisierung der physikalischen Festplatten

Manche Ordner oder Aufgaben lassen sich im Aufgabenplaner nicht löschen „Das Benutzerkonto hat keine Berechtigung“

Veröffentlicht am von — Keine Kommentare ↓

Manchmal schleichen sich Ordner und Tasks im Aufgabenplaner ein, die man nicht ohne weiteres löschen kann. Windows meldet „Das Benutzerkonto hat keine Berechtigung zum löschen dieser Aufgabe“ oder „Das Benutzerkonto hat keine Berechtigung zum löschen dieses Ordners“.

Lösung

Alle Aufgaben werden in diesem Registry-Zweig abgelegt:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache\Tree

Darin kann man die Ordner sehen, eventuell „unsichtbare“ Aufgaben entfernen, Berechtigunen korrigieren und nach Herzenslust gleich ganze Bäume entfernen.

WordPress und Word 2010 („Der Beitrag konnte nicht veröffentlicht werden“)
.NET Framework 3.5 unter Windows 8.1 installieren
VMware vSphere "Der Vorgang ist im aktuellen Zustand nicht zulässig"

Ein im lokalen ActiveDirectory gelöschter Benutzer wird nicht von AADConnect in Microsoft 365 gelöscht

Veröffentlicht am von — Keine Kommentare ↓

Es tritt manchmal das Problem auf, das ein gelöschtes AD-Objekt (Benutzer) aus dem lokalen („OnPremises“) ActiveDirectory (EXAMPLE.LOCAL) nicht in das AzureAD synchronisiert wird, also dort nicht ebenfalls entfernt wird. „Normalerweise“ sollte das aber der Fall sein.

Das Objekt ist in diesem Fall weiterhin in Microsoft 365 sichtbar, kann aber auch im Portal (https://portal.office.com) nicht entfernt werde. Das passiert dann, wenn die Verzeichnissynchronisierung ein bestimmtes Cloud-Objekt „unerwartet“ nicht löschen kann und führt zu einem verwaisten Azure AD-Objekt, das von einem Administrator direkt entfernt werden muss.

Lösung (Windows 10+)

  • Wenn nicht vorhanden, AzureAD/MSOnline PowerShell Modul installieren
    Install-Module -Name MSOnline
  • Mit dem AzureAD (Microsoft 365 Tenant) als „Globaler Administrator“ verbinden
    Connect-MsolService
  • Objekt suchen mit
    Get-MsolUser -UserPrincipalName [email protected]
    … oder mit
    Get-MsolUser -SearchString "nam"
  • Wenn gefunden, Objekt(e) entfernen
    Get-MsolUser -UserPrincipalName [email protected] | Remove-MsolUser
Server 2016/Windows 10 Software im "Abgesicherten Modus" deinstallieren
Microsoft SQL Server (MSSQL) model, tempdb, msdb und master Datenbank verschieben
Windows 7 msg.exe - Fehler xxx beim Abrufen der Sitzungsnamen

Microsoft 365 und Office 365 neue Namen

Veröffentlicht am von — Keine Kommentare ↓

Die ist eine Notiz an mich selber, weil ich die neuen Bezeichner für die Microsoft/Office 365 Produkte noch immer och so sicher verwenden kann, wie die alten 🤯

Office 365 Business Essentials ➡ Microsoft 365 Business Basic

Office 365 Business Premium ➡ Microsoft 365 Business Standard

Microsoft 365 Business ➡ Microsoft 365 Business Premium

Office 365 Business ➡ Microsoft 365 Apps for Business

Office 365 ProPlus ➡ Microsoft 365 Apps for Enterprise

Windows Server 2012R2 mit ABE hat hohe CPU-Last (Gestbeitrag von Andreas)
Outlook Abwesenheitsassistent Automatische Antworten - Server nicht verfügbar
In Office 365 mit der Powershell die Benutzerkontaktdaten wie Straße oder Ort Massenhaft ändern

PowerShell installation von NuGet schlägt fehl („Es kann kein Download von URI…“)

Veröffentlicht am von — 1 Kommentar ↓

Problem

Für viele Dinge in der PowerShell, beispielsweise auch das MSOnline Modul, wird der NuGet Paketmanager benötigt. Die Module wissen das normalerweise auch und wollen diesen gleich mitinstallieren. Dieser vorgang schlägt aber recht oft fehl:

PS C:> Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201
WARNUNG: Es kann kein Download von URI "https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409" nach "" durchgeführt werden.
WARNUNG: Die Liste der verfügbaren Anbieter kann nicht heruntergeladen werden. Überprüfen Sie Ihre Internetverbindung.

Install-PackageProvider : Für die angegebenen Suchkriterien für Anbieter "NuGet" wurde keine Übereinstimmung gefunden. Der Paketanbieter erfordert das PackageManagement- und
Provider-Tag. Überprüfen Sie, ob das angegebene Paket über die Tags verfügt.
In Zeile:1 Zeichen:1
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201
~~~~~~~~~~~~~ CategoryInfo : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception
FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider

Lösung

Eine funktionierende Internetverbindung vorausgesetzt, liegt es vermutlich an dem „Upgrade“ des Azureedges, der den Lookup-Provider stellt (onegetcdn.azureedge.net/providers). Der Endpunkt lässt seit etwa April 2020 keine TLS1.0 Verbindungen mehr zu und wurde auf „TLS1.2 min“ konfiguriert. Die PowerShell (<14393.3474) spricht per Default aber nur TLS1.1.

Dieser PS-Befehl stellt die PowerShell ebenfalls auf 1.2 um:

[Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12

Danach funktioniert sofort der Modulinstaller wieder – und alles andere auch.

Server 2008R2/Windows 7 Service Pack 1 Fehler 0x800f0a12
Windows-Update Fehler „13EC“
Ein im lokalen ActiveDirectory gelöschter Benutzer wird nicht von AADConnect in Microsoft 365 gelösc...

„Die Druckereinstellungen konnten nicht gespeichert werden.“ Dieser Vorgang wird nicht unterstützt.

Veröffentlicht am von — Keine Kommentare ↓

Auf Windows Druckserver schlägt es manchmal fehl, den Treiber eines Druckers zu aktualisieren oder neu zu installieren. Die Einrichtung läuft scheinbar zuerst fehlerfrei durch, doch nach dem „OK“ Klick am Ende erschient die Fehlermeldung „Die Druckereinstellungen konnten nicht gespeichert werden. Dieser Vorgang wird nicht unterstützt.“

Lösung

Abhilfe schafft es, die Option „Drucker freigeben“ aus- und wieder ein zu schalten.

Bevor der Treiber geändert werden kann, muss die Freigabe des Druckers aufgehoben werden, nach der Aktualisierung kann der Haken wieder rein.

Server 2016/Windows 10 Software im "Abgesicherten Modus" deinstallieren
BitLocker fragt ständig nach Recovery-Key
ActiveDirectory: Liste aller Computer mit Betriebssystem in einer OU erstellen