Swyx Server Line Manager kollidiert mit Windows DNS Server Ports

Problem

Auf einem Swyx Server werden nach einem Reboot oder Dienstneustart des SwyxLinkManager die angelegten SIP-Trunks nicht mehr korrekt (oder nicht mehr alle) angemeldet. Manchmal funktioniert die Bereitstellung der Trunks auch scheinbar fehlerfrei, aber es kann nur in eine „Richtung“ telefoniert werden. Beispielsweise ist eine eingehende Rufsignalisierung kein Problem, die ausgehende funktioniert aber nicht. Dieses Verhalten scheint nicht reproduzierbar, sondern stellt sich „mal so mal so“ dar. Das passiert hauptsächlich auf Maschinen mit Windows DNS-Server.

Lösung

Der „SwyxLinkmanger“ benötigt für die einwandfreie Funktion folgende (UDP-)Ports:

SwyxServer 51000-51499
LinkManager55000-56000

Verbindungen unterteilen sich dabei in „Callcontrol“ (für den Verbindungsauf- und Verbindungsabbau) sowie die „Payload-“ oder „Datenphase“ in der der eigentlich Versand der Datenpakete mit Audio- oder Faxinhalten stattfindet.

Audiodaten werden immer per UDP Protokoll übertragen. Faxdaten hingegen können per UDP (überwiegend) oder TCP übertragen werden. Die Voreinstellung ist, zumindest bis SwyxWare v4.10, UDP. Sowohl die Quell- als auch die UDP/TCP-Zielports kommen aus den oben aufgeführten Bereichen.

Diese werden nun gerne beim starten des Windows DNS Dienstes belegt; dieser belegt eine ganze Menge an listener-Sockets im guten Glauben an viel DNS-Traffic. Man kann (und sollte) diese Ports einfach im DNS Server blockieren, dann entstehen keine Konflikte und die Telefonie funktioniert auch nach einen Reboot.

c:\> dnscmd /Config /SocketPoolExcludedPortRanges 51000-51490 55000-56000
c:\> sc stop dns & timeout 3 & sc start dns

Windows Server 2012/2012R2 RDS und/oder Windows 8/8.1/10 hängen bei „abmelden“ ewig fest

Problem

Wir sehen öfter den Fehler, das ein Windows Server 2012 RDS Session Host beim abmelden hängenbleibt. Das auch gerne ausdauernd lange. Dieses Verhalten lässt sich reproduzieren, wenn das Kennwort des angemeldeten Benutzers geändert wird.

Lösung

Das liegt (meist) an dem fehlenden Fix KB3132080, der diesen Effekt zwar behebt, aber andere Probleme mitbringt.

Es geht für den schnellen Admin aber auch manuell und flott, wenn man einfach die hängenden RDP-Sessions manuell beendet.

CMD-Session auf dem betroffenen Host öffnen:
C:\> psexec \\<MEINSERVER> cmd

offene RDP-Sessions auflisten:
C:\Windows> query session

offene RDP- Session beenden
logoff <ID>

IIS mit PHP Berechtigungsfehler beim Upload von Dateien

Unter Windows mit einem IIS und PHP habe ich soeben STUNDEN damit zugebracht, herauszufinden warum meine hochgeladenen Bilder (und Dateien) nicht die erforderlichen Berechtigungen für eine korrekte Anzeige aus dem Upload-Ordner erben. „Serverfehler 500“ sagt der IIS dazu ja auch nur und Bilder werden nicht angezeigt.

Das Problem tritt nur auf, wenn man PHP zum Hochladen nutzt. .NET hat das Problem generell nicht.

PHP legt hochgeladene Dateien nämlich in einem temporären Verzeichnis ab (Default: %windir%\Temp) und VERSCHIEBT diese danach ins Zielverzeichnis. Wenn eine Datei in dem temporären Upload-Verzeichnis angekommen ist, erbt sie (korrekterweise) erst einmal die NTFS-Berechtigungen dieses Verzeichnisses. Verschieben der Datei auf dem selben Laufwerk erhält dann aber die Berechtigungen dieser Datei und diese erbt die Berechtigungen des Ziel-Webverzeichnisses nicht. Verschiebt man über Volumengrenzen hinweg, tritt dieser Fehler nicht auf: Neue Dateien erben dort die NTFS-Berechtigungen des Zielordners. Das ist so, weil verschiebeoperationen eines Volumes nur den Pointer einer Datei ändern, die anhängenden ACLs und Metadaten aber nicht.

Lösung

Der einfachste Weg dieses Problem zu beheben besteht darin, die Berechtigungen der Ziel-Webverzeichnisses auf das temporäre Upload-Verzeichnis zu übertragen, bzw. die ACLs zu ergänzen. Einfach die Berechtigungen des Webverzeichnisses zum TEMP-Verzeichnis hinzufügen.

  1. Das temporäre Upload-Verzeichnisses in der php.ini-Datei in dem Parameter „upload_tmp_dir“ festgelegt. Ist kein Eintrag festgelegt, verwendet PHP %TEMP%
  2. In diesem Ordner alle Berechtigungen des Ziel-Webordners hinzufügen.

Windows 8/10: DNS-Namensauflösung über VPN-Verbindung erzwingen

Ein weit verbreitetes Problem bei Windows VPN-Verbindungen (RAS/RRAS) ist das Erzwingen der DNS-Namensauflösung über den VPN-Tunnel. Unter Windows ab Version 8 versucht Windows „smart“ zu sein und vermeintlich externe Domains über den Standart-Resovler aufzulösen.

Daher funktioniert die Namensauflösung für VPN-Clients of nicht korrekt und interne Ressourcen sind nicht erreichbar oder werden falsch aufgelöst.

Der Trick an der Sache: Standardmäßig verwendet Windows ab 10 die Routen- sowie Schnittstellenmetrik nicht mehr ausschliesslich für die Route zu einem Paket-Ziel, sondern auch für die Auswahl des „besten“ DNS-Resolvers. Sofern es nur um eine Verbindung geht klappt das ja auch ganz gut.

Lösung

Man vergibt für die VPN-Schnittstelle einfach eine kleinere Metric. Eine deutlich kleinere als die Schnittstelle der LAN-Verbindung hat (Default: ‚Automatisch‘, normalerweise zwischen 280 und 3800).

Start > Einstellungen > Netzwerk und Internet > Adapteroptionen ändern > VPN-Verbindung auswählen > Eigenschaften > Tab „Netzwerk“ > Eigenschaften > Erweitert > „Schnittstellenmetrik“. Hier etwas kleines eintragen, zum Beispiel „5“.

Nach dem erneuten einwöhlen klappt’s auch mit der Namensauflösung.

Quelle: Sehr tief vergrabener Technet-Artikel unter https://blogs.technet.microsoft.com/networking/2015/08/14/adjusting-the-network-protocol-bindings-in-windows-10/

„Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden.“ mit Office 365 ProPlus

Trotz korrekter Terminalserver-Installation kommt es seit Ende der Jahres 2018 unter Windows Server 2016 in einer RDS-Umgebung häufiger zu diesem Fehler beim Start der Office-Anwendungen:

Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.
Diese Kopie von Microsoft Office kann auf einem Computer, der die Terminaldienste ausführt, nicht verwendet werden. Damit Microsoft Office auf einem Computer, der die Terminaldienste ausführt, verwendet werden kann, müssen Sie eine Volumenlizenzedition von Office verwenden.

Der Inhalt dieser Meldung ist mit Office ProPlus natürlich Unsinn und nur ein Überbleibsel aus vergangenen Tagen. Office ProPlus (oder auch „O365ProPlusRetail“) dürfen durchaus in RDS-Umgebungen genutzt werden.

Eigentlich sorgt bei der Installation der Klick-und-Los Variante („setup /configure“) der Eintrag „SharedComputerLicensing“ in der XML-Datei für die richtige Konfiguration; das scheint aber nicht immer so richtig zu klappen. Vor allem unter Office 2019 (das nur Office365 heißt) ist das der Fall – vermutlich weil sich der zugehörige Registry-Schlüssel geändert hat. Früher wohnte dieser in Office\<version>\ClickToRun, nun entfällt <version>.

„Richtige“ Bereitstellungsdatei

<Configuration>
  <Add OfficeClientEdition="32" Channel="Monthly">
    <Product ID="O365ProPlusRetail">
      <Language ID="de-de" />
    </Product>
  </Add>
<Updates Enabled="TRUE" Channel="Monthly" />
<Display Level="NONE" AcceptEULA="TRUE" />
<Property Name="AUTOACTIVATE" Value="1" />
<Property Name="SharedComputerLicensing" Value="1" />  <--_HIER____
</Configuration>

Lösung

Wenn das mal wieder nicht so recht geklappt zu haen scheint, kann man den notwendigen Registry-Eintrag jederzeiot von Hand hinzufügen und schon ist Office wieder Terminalserver-Fähig.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
   Name: SharedComputerLicensing
   Typ: REG_SZ ("Zeichenfolge")
   Inhalt: 1

Es ist kein reboot notwendig, nach einem Neustart der Anwendungen läuft Office ohne Fehler.

Windows Server 2019 Aktivierung – Der eingegebene Produkt Key funktioniert nicht (0x80070490)

Problem:

Man hat gerade frisch aus dem VLSC das Windows Server 2019 ISO heruntergeladen und möchte die installierte Maschine nun mit dem zugehörigen MAK-Schlüssel aktivieren.

Nach Eingabe des Keys zeigt einem der Aktivierungsassistent allerdings nur die Fehlermeldung:

Der eingegebene Produkt Key funktioniert nicht. Überprüfen Sie den Produkt Key, und versuchen Sie es noch einmal, oder geben Sie einen anderen Produkt Key ein. (0x80070490)

Produkt Key Assistent

Lösung:

Es gibt wohl einen Bug in dem Grafischen Produkt Key Assistenten. Man muss den Key entweder bereits während der Installation angeben oder an der Konsole per slmgr installieren:

slmgr /ipk AAAAA-BBBBB-CCCCC-DDDDD-EEEEE

Danach könnte es noch einen Moment dauern, bis die Aktivierung in den Windows Einstellungen auch korrekt angezeigt wird. Von eventuellen Fehlermeldungen, welche dort direkt nach der Key-Installation angezeigt werden, sollte man sich also zunächst nicht irritieren lassen.

Office 365 Exchange Online Powershell unter Windows 10 Verbindung herstellen

Die Office 365 Exchange Online Powershell benötigt eigentlich keine Powershell Modul-Installation, weil zu Exchange nur eine Remote-Session hergestellt wird.

Anders sieht da aus, wenn man die MFA (Mehr-Faktor-Authentifizierung) eingeschaltet hat. Dazu unten mehr.

Exchange Online Powershell ohne MFA

$credential = Get-Credential
$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" -AllowRedirection
Import-PSSession $exchangeSession -DisableNameChecking -AllowClobber

Das erste Kommando fragt die Credentials ab und speichert diese in der Variable $credential, das zweite verwendet diese für die Verbindung und das dritte importiert die Remote-Sitzung.

Exchange Online Powershell mit 2FA (Mehr-Faktor Authentifizierung)

Hierfür muss man zuerst doch noch manuell ein Modul herunterladen, das „Exchange Online Remote PowerShell-Modul„. Man findet den Download für die Offline-Installation innerhalb seines Office 365 Portals in der EAC. Mann kann diese Spezial-Powershell aber auch direkt ohne Umwege herunterladen und starten; der Link dazu steht weiter unten.

Office 365 Portal > Exchange Administrator Center (EAC) > Hybrid > „Konfigurieren“ (‚Das Exchange Online-PowerShell-Modul unterstützt mehrstufige Authentifizierung.‘)

Hat man das Modul heruntergeladen und installiert, sollte man einmal sein WinRM-Konfiguration testen. Ein lauffähiges WinRM-System mit eingeschalteter Basic-Authentifizierung (Default) ist Voraussetzung.

WinRM-Konfiguration in der Powershell „als Administrator“ anschauen:

winrm get winrm/config/client/auth

Sollte da „Basic = false“ in der Ausgabe stehen, muss man zwingend Basic-Auth einschalten:

winrm set winrm/config/client/auth @{Basic="true"}

Dann kann man auch schon endlich fast eine Verbindung herstellen; dazu das „Microsoft Exchange Online Powershell Module“ im Startmenü öffnen. Dier hier ist der direkte Download-Link zur Exchange Shell:

https://cmdletpswmodule.blob.core.windows.net/exopsmodule/Microsoft.Online.CSE.PSModule.Client.application

In der neuen Exchange-Powershell tippt man dann:

Connect-EXOPSSession -UserPrincipalName <[email protected]>

Und schon stehen einem die altbekannten CMDlets wie Get-Mailbox, Get-DistributionGroup oder Get-MailboxPermission zur Verfügung.