RemoteApps sind eine feine Sache bei der Arbeit mit Terminalservern, schließlich muss es nicht immer ein vollständer Desktop sein. Kommen allerdings mobile Computer (aka Notebooks) ins Spiel, ist es nicht immer wünschenswert jede RemoteApp z.B. wegen eines externen Termins zu schließen, um sie im Anschluss wenn man wieder da ist, erneut zu starten.

Mit dem Bordmittel-Befehl „tsdiscon“ lassen sich Sitzungen leicht trennen. Damit das Ganze für bestimmte Server als auch Benutzer möglichst einfach und mit Sicherheitsabfrage klappt, wurde folgendes Skript erstellt:

@echo off

title RemoteApps trennen

cls

rem Konfiguration

 rem Benutzername und Terminalserver mittels Blindparameter uebergeben.

  set SessionUsername=%1
  set WTSServer=%2

 rem Wird kein Parameter uebergeben, den aktuell angemeldeten Benutzer und den lokalen Computer verwenden.

  if %SessionUsername%.==. set SessionUsername=%username%
  if %WTSServer%.==. set WTSServer=Localhost

rem Aktuelle Sitzungen auflisten

 query session /server:"%WTSServer%" | find "%SessionUsername%" > "%TEMP%\Session.txt"
 set /p Session=<"%TEMP%\Session.txt"

rem ID des Benutzers ermitteln

 rem Ab Zeichen 43 in der Zeile,
 rem drei Stellen in die Variable schreiben.

  set SessionID=%Session:~43,3%

 rem Ggf. vorhandene Leerstelle(n) entfernen, falls die ID nur ein- oder zweistellig ist.

   set "SessionID=%SessionID: =%"

rem "Session.txt" entfernen

 del "%TEMP%\Session.txt" /q

rem RemoteApps trennen

 :Abfrage
 echo.
 set /p Answer=RemoteApps von "%WTSServer% - %SessionUsername%" trennen (Ja/Nein)?

 if /i %answer%==j tsdiscon %SessionID% /Server:%WTSServer% & goto EOF
 if /i %answer%==n goto EOF
 echo.
 echo Ungueltige Eingabe
 goto Abfrage

 :EOF

Das Skript kann lokal auf dem Client oder auf dem Server gestartet werden. Werden keine Parameter angeben, wird der aktuelle Benutzername und „Localhost“ als Server verwendet.

Alternativ kann sowohl Benutzername als auch Servername oder -IP übergeben werden:

DisconnectRemoteApp.cmd <Benutzername> <Terminalserver>

Zum Beispiel:

DisconnectRemoteApp.cmd aweber 192.168.0.13

Bevor die Verbindung getrennt wird, erscheint eine Sicherheitsabfrage:

Einziger Schönheitsfehler auf Client-Seite nachdem die Verbindung getrennt wurde ist folgende Meldung:

Getestet mit Windows 8.1 Pro und Windows Server 2012 R2.

Beim Starten von RemoteApps werden im Gegensatz zum vollständigen Desktop keine Autostart-Einträge, Anmeldeskripte oder entsprechend konfigurierte Aufgaben ausgeführt. Dies führt je nach Umgebung oder Abhängigkeiten zu Schwierigkeiten, wenn z.B. keine Netzlaufwerke verbunden werden.

Nach kurzer Recherche fand sich die Lösung bei IT Explorations:

• Den Registrierungs-Editior (regedit) starten.
• Zu „HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd“ wechseln.
• Den Wert der Zeichenfolge „StartupPrograms“ bearbeiten und um die gewünschten Autostart-Einträge (Komma getrennt) erweitern. Z.B.:

  rdpclip,"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\Anmeldeskript.cmd"

  Bemerkung: „rdpclip“ ist per Standard bereits eingetragen. In diesem Beispiel ist ein Anmeldeskript im Autostart-Ordner aller Benutzer hinterlegt.

Quelle:

IT Explorations – RemoteAPP ignoriert Autostart

Bei der Installation des aktuellen MySQL Server (Community, 64-bit) auf einem Windows Server 2012 R2 Standard streikte der Installer. Im Log fand sich der Hinweis des die „Visual Studio 2013 Redistributable“-Laufzeitumgebung fehlen würden, obwohl diese zu Beginn des Setups vom Installer bereits automatisch heruntergeladen und installiert wurde.

Ein Neustart des Installers änderte an der Meldung nichts. Eine (extrem) kurze Suche im Netz brachte die Lösung:

Sowohl das 32- als auch 64-bit „Visual Studio 2013 Redistributable Pakage“ herunterladen und installieren, dann klappt’s auch mit dem MySQL Server-Setup.

Microsoft Download Center – Visual C++ Redistributable Packages für Visual Studio 2013

Quelle:

stack overflow – MySql 5.7 installer fails to detect VS 2013 redistributable

Bei ein paar Kunden gab es Schwierigkeiten, das diese nicht jeden Anrufen konnten. Die Kunden selbst konnten immer erreicht werden. Seltsam war dabei, des dies erst seit ca. drei Wochen der Fall war.

Auffällig war zudem, das alle betroffenen Kunden bei der Telekom sind, VoIP-Anschlüsse haben und die nicht erreichbaren Ziele bei anderen Provider liegen (aktuell bekannt ist Vodafone, Ecotel und NTTCable). Am Router sollte es nicht liegen, da zum einen unterschiedliche Modelle (z.B. FritzBox, pfSense, Securepoint, …) um Einsatz kommen und die Telefonanlagen sich direkt beim Provider registrieren (die Router machen nur die Interneteinwahl).

Kurios war zudem, das es bei einem Kunden nicht immer die gleichen Ziele waren, bei einem anderem wiederum hundertprozentig reproduzierbar immer die Gleichen, beim nächsten sogar nur wenn ein ISDN-Anschluss angerufen wurde.

„Eigentlich“ sollte es solche Codec-Schwierigkeien wohl nur zwischen VoIP-Endgeräten geben, meinte mal ein Telekom-Techniker, am Beispiel des ISDN-Ziels ist’s dann aber wohl doch eine Provider-Angelegenheit. Jetzt kann man vermutlich haarspalterei betreiben, das schließlich der Übergabepunkt (media gateway) der VoIP auf ISDN wandelt dann quasi das Endgerät darstellt. Sei’s drum.

Jedenfalls wurde weder bei unseren Kunden noch bei den Angerufenen die letzte Zeit irgendetwas geändert. Die Suche nach der Ursache gestaltete sich zudem etwas schwierig, da in den Protokollen nichts vermerkt war und die Telekom-Technik (wir haben da im Laufe der vergangenen Tage mehrere Leute mit beschäftigt) jenseits der üblichen eigenen Tests kaum was getan hat. Eine Hotlinerin meinte sogar zu mir „wie soll man das nur finden“. Wenigstens hatte mich der letzte Hotliner auf die Codecs und mögliche Aushandlungsprobleme aufmerksam gemacht.

Einen SIP- und Network-Trace später hatte man folgendes sozusagen inder Hand:

SIP-Trace:
<--- SIP read from UDP:Ö-IP:5060 --->
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 192.168.96.5:5060;received=Ö-IP;rport=5060;branch=z9hG4bK48dcd1e1
To: <sip:ZIELRUFNUMMER@tel.t-online.de>;tag=h7g4Esbg_p65543t1507200306m243398c1467152066s1_1792797809-1923613878
From: "QUELLRUFNUMMER" <sip:+49QUELLRUFNUMMER@tel.t-online.de>;tag=as0b893270
Call-ID: 06e56b9908bc690f1116f8561cc3b382@tel.t-online.de
CSeq: 103 INVITE
Contact: <sip:sgc_c@217.0.23.100;transport=udp>
Reason: Q.850;cause=111;text="5"
upported: timer
Content-Length: 0

Network-Trace:
Session Initiation Protocol (500)
 Status-Line: SIP/2.0 500 Internal Server Error
 Message Header
 Via: SIP/2.0/UDP 192.168.96.5:5060;received=Ö-IP;rport=5060;branch=z9hG4bK3aece4f3
 To: <sip:ZIELRUFNUMMER@tel.t-online.de>;tag=h7g4Esbg_p65543t1507662901m951489c1517655816s1_532037588-1736118698
 From: "QUELLRUFNUMMER" <sip:+49QUELLRUFNUMMER@tel.t-online.de>;tag=as1309e071
 Call-ID: 2530625568be80105b2098c105ffcb15@tel.t-online.de
 CSeq: 103 INVITE
 Contact: <sip:sgc_c@217.0.23.100;transport=udp>
 Reason: Q.850;cause=111;text="5"
 Reason protocols: Q.850
 Cause: Protocol error, unspecified (111)
 Text: 5
 Supported: timer
 Content-Length: 0

Der SIP-Fehler „500 Internal Server Error“ ist erstmal relativ nichts sagend. Interessanter ist dann darunter

Reason: Q.850;cause=111;text="5"
Reason protocols: Q.850
Cause: Protocol error, unspecified (111)

Im SIP-Trace habe ich das irgendwie übersehen, erst im Wireshark viel mir das so richtig auf. Danach im Netz gesucht stolpert man sofort über Schwierigkeiten beim Verbindungsaufbau, wenn die Aushandlung des Codecs scheitert.

Daraufhin die Reihenfolge der Codecs im Provider- als auch in den Geräte-Konten in der Askozia geändert (ein Telefonneustart ist übrigens nicht notwendig) und siehe da, es geht. Ob die Änderung weitere/andere Auswirkungen hat und ob alle Schwierigkeiten damit behoben sind, muss man noch sehen.

Die voreingestellte Reihenfolge bei Askozia ist:

G.711 u-law
G.711 A-law
GSM

u- und A-law tauschen und speichern.

An manchen Stellen im Netz liest man zudem das „G.711 u-law“ komplett raus soll (unabhängig von Askozia, bezieht z.B. auf Asterisk im Allgemeinen oder auch Digitalisierungsboxen der Telekom und andere Telefonanlagen).

Nachfolgend ein paar (hoffentlich) hilfreiche Links:

Askozia Wiki – Help for integrators/de – SSH-Zugriff auf AskoziaPBX

Askozia Wiki – Help for integrators/de – Netzwerk-Tracing mit AskoziaPBX (weiter unten ist dann im Anschluss SIP-Trace beschrieben)

Askozia Wiki – Help for integrators – Audio Codecs

Telekom hilft Community – VOIP SIP 606 Fehler

Wikipedia – SIP-Status-Codes

Update 25.10.2017

Verspätet kam gestern noch eine Antwort vom Askozia-Support, man könne „u-law“ auch ganz entfernen.

Von Haus aus ist keine Datensicherung auf ein Netzlaufwerk oder UNC-Pfad so ohne weiteres mittels Wartungsplan möglich. Gebräuchliche Varianten bestehen darin, erst lokal zu sichern und anschließend diese zu verschieben oder direkt auf den UNC-Pfad zu sichern (sofern das Dienstkonto des MS SQL Servers zuvor im Ziel entsprechend berechtigt wurde, Domänenmitgliedschaft vorausgesetzt).

Bei einem Kunden-Szenario musste aus Platzgründen auf einen Backup-Server gesichert werden, dieser ist nicht Mitglied der Domäne, folglich waren die üblichen Wege keine Option. Nach kurzer Recherche war ermittelt, wie man dennoch direkt auf ein Netzlaufwerk unter Angabe von Anmeldedaten sichern kann:

Um ein Netzlaufwerk zu verbinden wird auf xp_cmdshell zurückgegriffen, dies ermöglicht Windows-Befehle direkt aus der Datenbank-Engine heraus ausführen zu können. Per Voreinstellung ist diese Option deaktiviert. Einschalten kann man diese entweder über das Management Studio oder über eine Abfrage:

Via GUI:

• Das „MS SQL Management Server Management Studio“ starten und anmelden.
• Im Objekt Explorer den Server mit der rechten Maustaste anklicken und „Facets“ auswählen.
• „XPCmdShellEnabled“ von „False“ auf „True“ ändern und auf „OK“ klicken.

Via Abfrage:

Siehe Quellen

Netzlaufwerk verbinden (via Abfrage):

EXEC XP_CMDSHELL 'net use m: \\<HOST>\<SHARE> <PASSWORD> /User:<HOSTNAME><USERNAME> /persistent:yes'

Ein erster Test z.B. durch das Auflisten des Laufwerksinhalts:

EXEC XP_CMDSHELL 'dir m:'

Ggf. die Laufwerksbuchstaben anpassen.

Klappt der Zugriff soweit, können die Wartungspläne entsprechend angepasst werden.

Vorteil dieser Methode ist das die Datensicherung nun auf einen anderen Server der zudem in einen anderen Brandabschnitt erfolgt. Lokal wird Speicherplatz gespart. Theoretisch könnte man mittels VPN sogar direkt an einen anderen Standort sichern, dabei wäre allerdings Verbindungsstabilität, Bandbreite und die Größe der Sicherung zu beachten. Nachteil ist eine zum Zeitpunkt der Sicherung höhere Netzlast und das die Sicherung ggf. länger dauert als lokal (abhängig von der Bandbreite).

Netzlaufwerk dauerhaft (auch nach MS SQL- oder Server-Neustart) verbinden

Wird der Datenbankdienst oder gar der komplette Server neugestartet, so steht das Netzlaufwerk nicht mehr zur Verfügung. Damit die „EXEC…“-Anweisung bei jedem Start von MS SQL ausgeführt wird, muss eine automatische Ausführung einer gespeicherten Prozedur eingerichtet werden:

CREATE PROC map_drive_startup
As
EXEC xp_cmdshell 'EXEC XP_CMDSHELL 'net use m: \\<HOST>\<SHARE> <PASSWORD> /User:<HOSTNAME><USERNAME>'

sp_procoption  @ProcName = 'map_drive_startup'
, @OptionName = 'startup'
, @OptionValue = 'on'

Quellen:

MS MSDN Forums – SQL Server 2012 – Cannot Use Network Drive as a Backup Device (Dienstkonto und Rechte)

DBDiggers – Enable and work with XP_CmdShell in SQL Server 2008 R2

MSSQTtips.com – Make Network Path Visible For SQL Server Backup and Restore in SSMS

MS Developer – Varun Dhawan’s Blog – Backup and Restore SQL Server Database to a network shared drive

Update 18.10.2017

Autoamtsiches Verbinden nach SQL Server-Neustart ergänzt.

HELP WANTED! Gelöst, siehe Update 27.10.2017 – 21:36 Ich bin aktuell auf der Suche nach einer Lösung für folgende Aufgabe:

Bei einem Kunden werden alle ausgehenden E-Mail-Adressen durch postfix auf „info@domain.tld“ umgeschrieben. Das ist so gewollt und läuft seit Jahren. Nun soll aber per Server-Eye’s MailRoundTrip ein Monitoring des E-Mail-Ablaufs erfolgen, d.h. eine Adresse darf nicht umgeschrieben werden.

Jetzt bin ich in postfix nicht so firm und alle bisherigen Versuche klappten leider nicht. Von daher hier mal ein Ruf in die Runde, ob jemand einen Tipp hat oder unterstützend mitwirken kann?

Aktuell ist es so, das via header_checks die Nachrichten umgeschrieben werden:

/^From:.*<.*@domain.tld>.*$/		REPLACE From: NAME <info@domain.tld>
/^From:.*@domain.tld.*$/		REPLACE From: NAME <info@domain.tld>
/^Reply-To:.*<.*@domain.tld>.*$/	REPLACE Reply-To: NAME <info@domain.tld>
/^Reply-To:.*@domain.tld.*$/		REPLACE Reply-To: NAME <info@domain.tld>

Ich nehme an, man könnte evtl. mit sowas wie

if !/^From:<nichtinfo@domain.tld>...
endif

arbeiten.

Das Thema habe ich zudem auch bei debianforum.de gepostet:

Postfix, alle ausgehenden Mail-Adressen umschreiben mit einer Ausnahme

Update 27.10.2017 – 21:36

Letztlich ist es ganz einfach zu lösen, nachfolgend die aktuelle header_checks-Konfiguration:

if !/^From:.*<nichtinfo@domain.tld/i

/^From:.*<.*@domain.tld>/	REPLACE From: NAME <info@domain.tld>
/^From:.*@domain.tld/		REPLACE From: NAME <info@domain.tld>
/^Reply-To:.*<.*@domain.tld>/	REPLACE Reply-To: NAME <info@domain.tld>
/^Reply-To:.*@domain.tld/	REPLACE Reply-To: NAME <info@domain.tld>

endif

Ich war also schon nahe dran, zusätzlich habe ich noch einen Fehler gemacht postmap auf die header_checks anzuwenden, was vollkommen überflüssig ist, da diese direkt ohne Umwandlung abgearbeitet wird.

Wie heisst es so schön: Knapp daneben ist auch vorbei.

Jedenfalls vielen Dank an Peer Heinlein für die Unterstützung, die Erklärungen wie auch Geduld und letztlich die Lösung dieser Aufgabe.

Danke auch an alle die Mails geschickt oder Kommentare geschrieben haben.

Vor einer Weile rief mich ein Kollege an mit folgender Situation:

Bei einem seiner Kunden hatte ein Verschlüsselungstrojaner zugeschlagen, d.h. der Server, die Arbeitsplätze, alle für den Schädling erreichbaren Daten verschlüsselt. Da der Kunde vergessen hatte regelmässig die USB-Festplatte zu wechseln, auf die täglich die Datensicherung läuft, war das letzte verfügbare Backup gut ein halbes Jahr alt.

Soweit also ein Zustand quasi kurz vor grande inferno.

Kurzerhand wurde der Server, ein Windows Small Business Server, aus der Datensicherung wiederhergestellt, allerdings wollte dieser nicht so recht. Beim Starten gab es bereits Unstimmigkeiten, der angepeilte reguläre Betrieb klappte ebenfalls nicht.

Beim Wiederherstellen von „älteren“ Backups von Domänen-Computern, ganz gleich ob Domänen-Mitglied oder Domänencontroller, muss man immer bedenken, das sich inzwischen die Computer-Kennwörter geändert haben. Diese werden automatisch generiert und aktualisiert, je nach Windows-Version und ggf. eigener Konfiguration geschieht dies i.d.R. alle 30 Tage.

An dieser Stelle der Hinweis, das die folgende Vorgehensweise nur für einzelne bzw. alleinige Domänencontroller funktioniert! Hat man zwei oder mehr Domänencontroller im Einsatz sollte davon abgesehen werden, diese wieder ins Netz zu bringen (Stichwort: USN Rollback, dieses sollte unbedingt vermieden werden)!

Mein Vorschlag lautete, den Server vom Netzwerk zu trennen, allerdings muss die Netzwerkkarte mit einem Switch verbunden sein, damit ein „Link up“ vorhanden ist, dann im BIOS das Datum z.B. auf einen Tag nach der letzten erfolgreichen Sicherung stellen und erst dann die Wiederherstellung durchführen.

Hintergedanke dieser Vorgehensweise ist, das nach der Wiederherstellung das System erstmal sozusagen in einem bekannten Zeitrahmen ist. Wenn das soweit geklappt hat, aus Windows heraus das Datum ändern, damit das Betriebssystem „bewusst“ den Zeitwechsel mitbekommt. Erst dann wieder den Server ans reguläre Netzwerk anschließen.

Lange Rede, kurzer Sinn: Das hat soweit funktioniert, ist allerdings die Kurzfassung. Alle Details was zuvor und danach noch gelaufen ist, habe ich nicht mehr im Kopf. Wichtig war mir an dieser Stelle, den Kern der Lösung zu dokumentieren.

Schön wenn man am Montag-Morgen mit einer Speicherplatzwarnung bei einem Kunden durch das Monitoring begrüßt wird. Das ist soweit harmlos, da noch Puffer vorhanden ist, also kann man in Ruhe auf Ursachensuche gehen. So geschehen an diesem trüben und kalten Morgen.

Man könnte meinen, der Server, ein Windows SBS 2008 weiß das er abgelöst werden soll und gibt sich deswegen auf die letzten Tage nochmal Mühe einen zu Nerven (da gab es noch mehr Vorfälle als diesen hier). Der neue Server steht schon bereit bzw. wird gerade vorbereitet und dann geht es an die Migration. Damit wird der vorletzte SBS bei unseren Kunden abgelöst.

Zur Sache: Wenn langsam aber sicher der Speicherplatz schwindet, kann das jenseits vom „natürlichen“ Datenwachstum andere Ursachen haben. In diesem Fall lag es an der SharePoint-Datenbank des SBS. Genauer ausgedrückt lag es am Transaktionsprotokoll, das mittlerweile 11.5 GB an Größe erreicht hatte. Da dieses auf Laufwerk C: unter

C:\Windows\SYSMSI\SSEE\MSSQL.2005\MSSQL\Data

liegt und zudem „nur“ SSDs mit einer Kapazität von 240GB zum Einsatz kommen, wurde es langsam zusammen mit allen anderen Programmen und Daten knapp.

Da SharePoint bei diesem Kunden nicht verwendet wird, wurde schlicht die Datenbank bzw. Protokoll verkleinert und das Sicherungsmodell geändert. Die Lösung fand sich sehr schnell im Blog von Bent Schrader:

Bents Blog – SharePoint Datenbanken auf Windows Small Business Server 2008 verkleinern

Einfach wie beschrieben vorgehen.

Verwendet man Outlook (mit mehreren Profilen) und dazu läuft noch ein MailStore Client, der gerade Mails aus einer Datendatei (PST) archiviert oder in eben eine solche Datei exportiert, so kann Outlook in dieser Zeit nicht geöffnet werden.

Genau genommen startet Outlook dann schon, aber es läuft der Ersteinrichtungs-Assistent an, was an dieser Stelle eher weniger praktisch ist. Hatte man Outlook schon offen und startet dann erst den MailStore Client samt Archivierungs-/Exportaufgabe gibt es meines Wissens nach keine Schwierigkeiten, das kommt möglicherweise darauf an, wer wohin archiviert. Ausgetestet ist das nicht.

Das Einstellen unter „Systemsteuerung – Mail“ das beim Start von Outlook abgefragt wird welches Profil genommen werden soll funktioniert an dieser Stelle leider nicht, da dennoch der Assi startet. Lösen kann man dies über einen gezielten Aufruf von Outlook mit dem Profil:

Die Outlook-Verknüpfung bearbeiten und bei Ziel (d.h. hinter „…\outlook.exe“)

/profile "<Profilename>"

anhängen. Nur „/profile“ um den Auswahldialog der Profile zu erhalten funktioniert übrigens nicht, es erscheint eine Meldung das Outlook nicht nochmal gestartet werden kann.

Ein wenig Hintergrund

Aktuell sammeln wir bei einem Kunden massenhaft PST-Dateien ein, da von Outlooks-Datendateien auf MDaemon mit Outlook Connector (OC) gewechselt wird. Damit die Bestandsdaten wie Mails, Termine, Kontakte, … übernommen werden können, läuft ein dedizierter Computer mit Office und MailStore Client, der den ganzen lieben langen Tag nur dazu da ist, die Daten zu migrieren. Während Termine & Kontakte einfach innerhalb von Outlook auf das OC-Konto umkopiert werden, archiviert MailStore die Mails aus den Datendateien, zum Zeitpunkt des Schreibens dieser Zeilen ist man bei knapp 300.000 Nachrichten angekommen, die Migration ist aber noch im Gange.

Bei (frisch installierten) Windows Server 2016 kann es durchaus sehr lange dauern, bis die eigentliche Installtion der Updates nach dem Download startet bzw. durchläuft.

In den vergangenen Tagen habe ich zwei Windows Server 2016 installiert. Nummer eins war eine OEM-Installation auf einem neuen Terra Miniserver, Nummer zwei eine virtuelle Maschine.

Bei der ersten Runde in Sachen „Windows Update“ lieferte der Miniserver den Fehler 0x800705b4. Ein weiterer Versuch klappte ebenfalls nicht, weswegen ich dann auf „sconfig“ auswich, da man dort (zumindest theoretisch) die Möglichkeit hat, das Update-Verhalten zu ändern und einzelne Updates auszuwählen.

Für den Anfang und weil’s bei früheren Versionen von Windows schnell ging, wurde erstmal das Defender-Update ausgewählt.

Aber nichts da mit schnell, weder in der Eingabeaufforderung noch in der Oberfläche der Einstellungen war ein Fortschritt zu erkennen. Die Ereignisprotolle lieferten ebenso wenig etwas brauchbares. Genauso war es mit „Get-WindowsUpdateLog“ in der PowerShell (dem neueren Pendant zum „WindowsUpdate.log“). Bei Blick in den Ressourcenmonitor offenbarte viel Aktivität bei „C:\Windows\Logs\CBS\CBS.log“:

Dieser Vorgang nahm über eine Stunde in Anspruch. Danach war keine Aktivität mehr festzustellen. „sconfig“ stand immer noch auf „Updates werden installiert“, unter „Einstellungen“ wurden nur die verfügbaren Updates aufgelistet. Erst ein Blick in den Updateverlauf zeigte, das entgegen der Auswahl bei „sconfig“ alle verfügbaren Updates installiert wurden und ein Neustart gefordert ist.

Nach dem Neustart standen keine Updates mehr zur Verfügung. Mal sehen, was nächsten Monat dann los ist.

Bei der virtuelle Maschine klappte die erste Runde der Windows Updates ohne Fehlermeldung, aber dennoch ackerte sich der Windows Server sich zunächst am „CBS.log“ ab, bevor nach einer Stunde die Updates installiert und der Server außerhalb der Nutzungszeit automatisch neu gestartet wurde.

Seltsames Neustartverhalten

Uneins ist sich Microsoft wohl auch was das Neustarten außerhalb der Nutzungszeit angeht. Während der Miniserver manuell neu gestartet werden musste, so machte dies die virtuelle Maschine von selbst. Bei ersterem lag das möglicherweise an der Fehlersituation.

Man ist wohl nicht alleine

Schaut man sich diesen Thread an, wird schnell klar, das man mit diesem Schwierigkeiten nicht alleine ist:

MS TechNet Forum – what’s with the really slow windows updates on 2016?

Bleibt zu hoffen, das Microsoft dies in den Griff bekommt und hoffentlich beim generellen Handling der Updates wieder auf das alte System zurückschwenkt, so das man ohne Umwege wieder einzelne Updates auswählen, installieren und dann neustarten kann, wann es passt (und nicht wann es Microsoft passt).

Schlussbemerkungen

Grundsätzlich bin ich persönlich weder bei Windows 10 noch Windows Server 2016 kein Freund davon, das diese automatisch irgendwann in einem 12-Stunden-Fenster neu starten. Problematisch dürfte dies sein bei unangekündigten Überstunden wie auch bei Umgebungen mit Mehrschichtbetrieb.

Das aktuell unberechenbare Updateverhalten kann darüber hinaus zum Problem werden, wenn man nur überschaubare Zeitfenster für die Wartung hat.

Zum Durchspielen einer Migration bietet es sich an, eine Datensicherung der Produktivumgebung in einer virtuellen Umgebung einzuspielen und dann Schritt-für-Schritt zu testen.

Diesen Plan wollten wir auch für einen abzulösenden Small Business Server 2008 verfolgen. Nach dem Restore als virtuelle Maschine auf einem Hyper-V Server 2012 R2 war zunächst die Überraschung groß, das der Exchange Server 2007 nicht rund lief. Genauer ausgedrückt wurden die Datenbanken nicht bereitgestellt. Im Ereignisprotokoll fanden sich Meldungen wie z.B. diese:

Im Zuge der Fehlerdiagnose mittels der bekannten eseutil-Befehle stießen wir dann bei „eseutil /r …“ (aka soft recovery) auf „Operation terminated with error -546 (JET_errLogSectorSizeMismatch, the log file sector size does not match the current
volume’s sector size) after 0.230 seconds.“

Ja wie, Probleme mit der Sektorgröße?! Daraufhin recherchiert fand sich dieser Blog-Beitrag:

Nano Tera Network Solutions – Exchange server 2007, log file sector size mismatch

Kurzfassung: Das Problem besteht darin, das neuere Festplatten und VHDX eine Sektorgröße von 4 Kilobyte, „klassische“ Festplatten und VHD 512 Byte, verwenden. Offensichtlich beziehen sich die Transaktionsprotokolle der JET-Datenbank (worunter z.B. Exchange und andere wie z.B. die DHCP-Server-Datenbank fallen) auf die Sektoren. Stimmt die Größe nicht mehr überein, gibt es Schwierigkeiten.

In diesem Fall, also virtuelle Umgebung, war es leicht eine neue VHD (ohne X) anzulegen und den Restore erneut durchzuführen. Bei physikalischen Laufwerken gilt bei Anschaffung auf die richtige Sektoregröße zu achten.

Alternativ soll es wohl möglich sein, das man zunächst zusieht, das alle Transaktionsprotokolle in die Datenbank geschrieben wurden, so das es keine Protokolle mehr gibt und dann den Exchange umzieht.

Der Recherche nach kann es diese Probleme auch mit Exchange Server 2010 geben. Ob weitere neuere Versionen ebenfalls davon betroffen sein können, wurde nicht nachgeschaut.

Nachfolgend ein paar Notizen und Links zum Windows Server 2016 (mit Desktop):

Windows Defender deaktivieren oder entfernen

Ab Windows Server 2016 liefert Microsoft den eigenen Virenschutz Defender auch für den Server mit. Dieser ist sozusagen ab Werk installiert und aktiv. Wer diesen nicht benötigt, kann ihn entweder über die GUI oder PowerShell deaktivieren oder über letztgenanntes ganz deinstallieren:

Windows Pro – Defender in Windows Server 2016 installieren und konfigurieren

Thomas Maurer – How to disable and configure Windows Defender on Windows Server 2016 using PowerShell

Nach der Deinstallation ist ein Neustart notwendig. In den Einstellungen bleibt der „Windows Defender“-Eintrag erhalten, ist allerdings ausgegraut und verweist auf die Verwaltung durch die Organisation (gemeint ist wohl der bzw. die Admin(s)).

Xbox-Dienste und Aufgaben deaktivieren

Warum auch immer haben zwei Xbox-Dienste und Aufgabe Einzug in den Windows Server gehalten. Diese kann und sollte man deaktivieren:

msitproblog – Disabling Xbox Services & Tasks in Server 2016 during OSD with ConfigMgr

Microsoft TechNet – Microsoft Security Guidance blog – Guidance on Disabling System Services on Windows Server 2016 with Desktop Experience

Windows Updates besser steuern

Statt über die GUI kann man über die Eingabeaufforderung mit dem Befehl „sconfig“ das Verhalten der Windows Updates besser kontrollieren und statt alle Updates nur bestimmte zur Installation auswählen.

Aber Achtung: Der Text „Nur Downloads“ ist nicht ganz zutreffend. Dieser Modus ist voreingestellt und läd nicht nur die Updates herunter, sondern installiert diese auch und führt den automatischen Neustart außerhalb der Nutzungszeit durch. Von daher ist die Einstellung „Manuell“ je nach Anspruch vielleicht die bessere Wahl.

Quelle: Tim Anderson’s ITWriting Disabling automatic update restarts in Windows Server 2016

Ein Nachteil wenn man via „sconfig“ die Updates herunterläd und installiert ist der fehlende Status. So lässt sich schlecht beobachten oder abschätzen, wie lange es noch dauert (oder überhaupt etwas gemacht wird). Einzig wenn die Installation abgeschlossen und ggf. ein Neustart notwendig ist, bekommt man dieses angezeigt:

Im Updateverlauf in den Einstellungen sieht man dies auch.

Als Abkürzung zum Suchen und Installieren der Windows Updates kann folgendes Skript verwendet werden:

@echo off

title Windows Update
cd "%windir%\System32\de-DE"
cscript WUA_SearchDownloadInstall.vbs

So spart man sich den Aufruf von „sconfig“ und das Drücken von „6) Updates herunterladen u. installieren“.

Automatischen Neustart außerhalb der Nutzungszeit verhindern

Es ist zwar nett gemeint, das man ein Zeitfenster, in der der Server verwendet wird angeben kann und außerhalb dieser Zeit Dieser automatisch nach der Installation von Updates neu gestartet wird. Je nach Umgebung oder Umstand kann dies allerdings unpassend sein. Um diesen Neustart zu verhindern, muss man die entsprechende Aufgabe ändern und den Befehl durch irgendwas anderes ersetzten. Ein Löschen oder Deaktivieren der Aufgabe nützt nichts, da diese dann wieder neu angelegt wird.

Aufgabenplanung - Microsoft - Windows - UpdateOrchastrator - Reboot

Quelle: MS TechNet Blog – Microsoft Update Product Team Blog – How to change Windows Update settings using SCONFIG. (Kommentar von Buckethead
April 5, 2017 at 12:46 am)

Alternativ die genannte Aufgabe (sofern vorhanden) löschen und einen leeren Ordner unter

C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator

anlegen. Dies soll verhindern, das eine neue Aufgabe mit dem Namen „Reboot“ erstellt wird, in Folge wird kein automatischer Neustart durchgeführt.

Quelle: Microsoft Partner Network – How to really manage Windows Update & reboot (Server 2016) for production environment?

Startmenü

Wem das neue Startmenü nicht zusagt, der kann wie zuvor bei Windows 8.x, Server 2012 w/o R2 und Windows 10 z.B. auf die Classic Shell zurückgreifen.

Stand-alone Terminalserver (aka Remote Desktop Session Host)

Der schnellste und einfachste Weg aus einem Windows Server 2016 einen stand-alone Terminalserver (ohne Domäne und Schnickschnack) zu machen besteht (imho) darin, den RDP Wrapper zu verwenden. Alternativ kann man es auch anderst zurechtbasteln:

DigitalBamboo’s Blog – Deploy Remote Desktop Services in a Workgroup or Domain Easily!

Um es Nutzern einfacher zu machen, Exchange- bzw. ActiveSync-Konten auf ihren Smartphone’s oder Tablets einzurichten, bietet es sich an AutoDiscover (aka AutoErmittlung) zu verwenden. Dadurch werden Anhand des Domänenanteils der E-Mail-Adresse automatisch der Mailserver ermittelt und SSL aktiviert. Der MDaemon Messaging Server zusammen mit der ActiveSync-Erweiterung bietet dazu fast alles nötige an.

Voraussetzungen

• MDaemon Messaging Server mit aktivierter und konfigurierter ActiveSync-Erweiterung. Die Dienste ActiveSync und AutoDiscover müssen aktiv sein (i.d.R. per Voreinstellung bereits gegeben).
• Subdomain nach dem Namenschema „autodiscover.domain.tld“. Diese Angabe ist obligatorisch!
• SSL/TLS-Zertifikat das auf die Domäne des Servers und die Subdomain für AutoDiscover ausgestellt ist. Dies funktioniert auch mit Let’s Encrypt und DDNS.
• Port 443/tcp (https) muss in der Firewall freigegeben sein.

DNS konfigurieren

Unterhalb der Haupt- bzw. Maildomäne eine Subdomain „autodiscover.domain.tld“ anlegen. Entweder per A- (bei fester öffentlicher IP-Adresse) oder CNAME-Eintrag (z.B. bei DDNS) auf den MDaemon-Server zeigen.

Am Beispiel von 1&1 zusammen mit einer DDNS-Domain bei spDYN sieht dies z.B. so aus:

Bis Änderungen im DNS greifen, können durchaus einige Stunden vergehen.

SSL/TLS-Zertifikat ausstellen und einbinden

Am Beispiel vom bei MDaemon mitgelieferten Let’s Encrypt-PowerShell-Skript könnte dies so aussehen:

LetsEncrypt.ps1 -AlternateHostNames autodiscover.domain.tld -To "admin@domain.tld"

Die Angabe der Mail-Domäne ist nicht notwendig, da das Skript den SMTP-Hostname automatisch verwendet.

Erster Test und Troubleshooting

Ein einfacher erster Test kann darin bestehen, via Browser folgende URL aufzurufen:

https://autodiscover.domain.tld/AutoDiscover/AutoDiscover.xml

Funktioniert die DNS-Auflösung, laufen die Dienste usw. erhält man eine Antwort in folgender Art:

Um den Erfolg oder Misserfolg von Zugriffen zu erkennen, kann man die Protokolle unter „Plugins – AutoDiscover, ActiveSync und Dynamischer Filter“ konsultieren. Bei zu vielen Fehlerversuchen kann es passieren, das man auf die Blacklist vom „Dynamschen Filter“ gelangt.

Quellen:

MDaemon – Online Hilfer – ActiveSync für MDaemon (Automatische Provisionierung durch ActiveSync Autodiscover)

MDaemon – Knowledge Base – How to setup the ActiveSync AutoDiscovery Service

MSDN – Erstellen von DNS-Einträgen bei 1&1

EBERTLANG – Blog – Feature-Lexikon: Konfiguration von „AutoDiscover“ für MDaemon

Apple iOS und Android konfigurieren

Apple – Exchange ActiveSync auf dem iPhone, iPad oder iPod touch einrichten

Bei Android kann die Einrichtung je nach Version, App und Hersteller variieren.

Outlook ab Version 2013 kann ebenfalls via ActiveSync angebunden werden.

Klassischerweise verwendet man unter Windows (Client als auch Server) die Computerverwaltung um sehen zu können, wer gerade mit welcher Freigabe verbunden ist und welche Dateien geöffnet hat.

Wenn es manchmal zu Schwierigkeiten kommt, kann man den Zugriff beenden bzw. den Nutzer abbmelden. So weit, so gut. Leider gibt es Dinge, die sich scheinbar nie ändern. Seit vielen Windows-Versionen beobachte ich das Problem, das beim Zugriff auf

Computerverwaltung - System - Freigegebene Ordner - Sitzungen

die MMC hängt oder gar abstürzt. So auch aktuell auf einem Windows Server 2016. Manchmal tritt dies direkt beim Aufruf auf, manchmal erst nach einer gewissen Zeit. Ärgerlich ist es in jedem Fall.

Um Sitzungen in der Eingabeaufforderung anzuzeigen kann man

net session

verwenden. Das Äquilvalet für geöffnete Dateien ist

net file

Alternativ kann auch

openfiles

verwendet werden. Via Parameter „/disconnect“ (net session und openfiles) oder „/close“ (net file) können Sitzungen und Zugriffe beendet werden.

Wer es grafisch jenseits der Bordmittel haben möchte, kann einen Blick auf NetworkOpenedFiles von Nir Sofer (aka Nirsoft) werfen.

Manchmal hat man Glück im Unglück: Während der Migration eines Windows SBS 2008 zu Windows Server 2016 Standard mit MDaemon Messaging Server starb die Securepoint UTM bei einem Kunden.

In Folge des Ausfalls klappte zunächst nicht die Zustellung bzw. der Abruf von Mails, da die UTM als Mail-Relay (SMTP-Versand als Smarthost) und Mail-Connector (Abruf von POP3-Konten) fungierte. Da die eigentliche Mail-Server-Migration schon durch war, d.h. der Exchange Server 2007 war bereits weg, dafür lief ein MDaemon Messaging Server, war das kein größeres Problem. Es wurde fix der Smarthost und MultiPop im MDaemon konfiguriert und schon liefen die Mails mit einem „Otto-Normal-Firewall-Router“ als Leihgerät zur defekten UTM wieder.

Mit Exchange hätte zwar der Versand per SMTP funktioniert, aber ein Abruf von POP3-Konten beim Provider ging mit den Bordmitteln des SBS schon lange nicht mehr und ein vom vorigen IT-Service verwendeter POPcon lief ebenfalls seit einiger Zeit nicht mehr.

Der Vollständigkeit halber sei erwähnt, das eine direkte SMTP-Anbindung beim Kunden bislang nicht möglich war (soll in Zukunft kommen). Die zusätzliche Sicherheit durch die Filter der UTM fehlt zwar aktuell, da aber Panda Adaptive Defense 360 zum Einsatz kommt, ist das (imho) zu verschmerzen.

Die UTM wird wieder, da noch nicht so alt, Instandgesetzt und wird dann wieder eingebunden.

Am vergangenen Wochenende wurde der einzige und zugleich letzte Windows Small Business Server 2008 bei einem Kunden zu Windows Server 2016 Standard migriert.

Im wesentlichen lief die Migration gemäss der Anleitung von Microsoft ab:

Migration von Windows Small Business Server 2008 zu Windows Server 2012 Essentials

Die Freigaben (es gab nur zwei: 1x Daten, 1x Anwendung) konnten schlicht mit Robocopy und Ändern des Anmeldeskripts migriert werden. Der Exchange wurde durch MDaemon ersetzt. SharePoint, Ordner-Umleitung etc. wurde nicht verwendet. DHCP wurde einfach neu angelegt.

Nach dem Hinzufügen des neuen Servers zur Domäne viel zunächst auf, das Sysvol nicht repliziert wurde. Dies wurde aufgrund eines Fehlers auf dem alten SBS hervorgerufen, der im Ereignis genannte Lösungsweg behob diesen Fehler (sorry, kein Screenshot oder Kopie davon vorhanden).

Die Deinstallation des Exchange Servers verlief nach einiger Handarbeit erfolgreich. Hilfreich war an dieser Stelle, die Deinstallation via

setup.com /mode:uninstall

durchzuführen, da es dort (imho) brauchbarere Fehlermeldungen gab.

Die Active Directory-Zertifikatdienste wehrten sich via Server-Manager (gemeint ist die GUI) deinstalliert zu werden. Trotz aller vorhandener Rechte war die Option ausgegraut. Die Deinstallation gelang letztlich in einer Eingabeaufforderung mit erhöhten Rechten und

servermanager -remove AD-Certificate

Ebenso wie die Deinstallation von Exchange braucht dies einige Zeit (trotz SSDs im alten Server jeweils über eine Stunde).

Da wir dem alten Server nicht mehr ganz vertrauten, wurden die FSMO-Rollen per Befehl verschoben. Unter Windows Server 2016 sieht das in einer PowerShell mit erhöhten Rechten dann so aus:

Move-ADDirectoryServerOperationMasterRole -Identity $env:ComputerName -OperationMasterRole 0,1,2,3,4 -confirm:$false

oder

Move-ADDirectoryServerOperationMasterRole -Identity $env:ComputerName -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Mit

netdom query fsmo

kann wie gewohnt geprüft werden, wer die Rollen inne hat.

Danach klappte der Herunterstufen und Entfernen des SBS 2008 aus der Domäne ohne Probleme.

Nicht vergessen, neue Zeitquelle konfigurieren:

w32tm /config /syncfromflags:manual /manualpeerlist:”ptbtime1.ptb.de, ptbtime2.ptb.de, ptbtime3.ptb.de”
w32tm /config /reliable:YES /update
w32tm /resync

Quellen

Vollständiges Entfernen von Exchange 2007 von einem Server

TechGenix – Using the new Windows Server 2008 Servermanager.exe CLI tool to Add & Remove Server Roles

Windows Server Essentials – Migrate SBS 2011 Standard to Windows Server 2016

Microsoft TechNet – Step-By-Step: Migrating Active Directory FSMO Roles From Windows Server 2012 R2 to 2016

fe80::dead:affe:beef – Externe Zeitquelle auf Domain Controller einrichten

Update 01.12.2017

Im „File Replication Service“-Ereignisprotokoll vielen noch Meldungen wie diese auf:

Protokollname: File Replication Service
Quelle:        NtFrs
Datum:         30.11.2017 12:05:54
Ereignis-ID:   13508
Aufgabenkategorie:Keine
Ebene:         Warnung
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      srv02.domain.local
Beschreibung:
Der Dateireplikationsdienst kann die Replikation von SRV01.domain.local nach SRV02 für c:\windows\sysvol\domain mit DNS-Namen SRV01.domain.local nicht aktivieren. Es wird ein neuer Versuch gestartet.
 Mögliche Ursachen für diese Warnung sind:

 [1] Der DNS-Name SRV01.domain.local von diesem Computer konnte nicht ausgewertet werden.
 [2] Der Dateireplikationsdienst wird auf SRV01.domain.local nicht ausgeführt.
 [3] Die Topologieinformationen in den Active Directory-Domänendiensten dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert.

 Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

Offenbar wurde der Server doch nicht so sauber entfernt beim Herunterstufen. Ein Blick in „Active Directory-Standorte und -Dienste“ unter „Sites – Default-First-Site-Name – Server“ zeigte, das dort noch der alte Server drin stand. Dieser Eintrag wurde gelöscht.

Es könnte so einfach sein, aber irgendwie haben wir mit Treibern von HP schon öfters kein Glück gehabt. So aktuell beim Servertausch bei einem Kunden.

Bislang und bei vielen anderen Druckern (und Servern) lief es bislang in der Regel so ab, das der neue Server eingerichtet wurde, die Druckertreiber installiert und die Drucker freigegeben wurden. Anschließend wird die Druckerverbindung auf den Arbeitsplätzen aktualisiert (d.h. alte Verbindung trennen, neue Verbindung herstellen).

Diesmal lief es aber anders: Nach dem Trennen der alten Verbindung und dem Versuch die Neue herzustellen stürzte die Druckwarteschlange auf den Windows 7-Arbeitsplätzen ab. Mehrmalige Versuche führten immer zum gleichen Ergebnis.

Startete man die Druckwarteschlange neu und versuchte über die Druckservereigenschaften den vorigen Treiber zu entfernen, erhielt man lediglich die Meldung, das dieser in Verwendung sei.

Folgende Schritte führten dann zum Erfolg, gemeint ist, die neue Verbindung herstellen zu können:

• Die Druckwarteschlange beenden (sofern noch nicht abgestürzt).
• Die Druckertreiber-Dateien unter „C:\Windows\System32\spool\drivers\x64\3“ die „HP*.*“, „M*.*“ und „XPS*.*“ enthalten löschen.
• Ggf. in der Registry unter „hkcu\printers\connectios“ die alten Verbindungen löschen.
• Die Druckwarteschlange starten.
• Über die Druckservereigenschaften den neuen Treiber manuell hinzufügen. Der Drucker steht zu diesem Zeitpunkt zwar schon bzw. noch in der Liste, da man die Treiberdateien allerdings per Hand gelöscht hat, funktioniert Dieser nicht mehr.
• Dann erst über „\\<Servername>\<Druckerfreigabename>“ die neue Verbindung herstellen.

Evtl. hilfreich, wenn auch bislang nicht getestet könnte folgendes sein:

tinte24.de – Drucker komplett deinstallieren – Windows 7 (siehe „Treiber-Deinstallation für Fortgeschrittene“)

TechRepublic – Discover the power of Windows 7 hidden VBScript print utilities

Nutzt man Firefox ab Version 56 über eine Remotedesktopverbindung oder als RemoteApp, so wird trotz entsprechender Konfiguration der Verbindung kein Audio wiedergegeben. Andere Anwendungen und Browser hingegen können Klänge, Musik oder Videos korrekt wiedergeben.

Allem anschein nach blockiert die neue Sandbox-Technik die Wiedergabe. Durch eine kleine Änderung klappts wieder mit dem Ton:

• Firefox starten
• In der Adresszeile

  security.sandbox.content.level

  eingeben und den Wert von „3“ auf „2“ ändern.

• Firefox neustarten.

Quelle:

Firefox Support – I can’t play audio on a Remote Desktop Connection

Seit den Windows Updates von Oktober oder November 2017 beobachten wir vermehrt das vor allem bei Domänencontrollern auf Basis von Windows Server 2012 R2 Standard nach einem Neustart die Netzwerkkategorie von „Domänennetzwerk“ zu „Öffentliches Netzwerk“ (oder schlicht „Öffentlich“) wechselt.

In wie weit andere Versionen und Editionen von Windows davon betroffen sein können, kann aktuell nicht sicher ermittelt werden. Auffällig war jedenfall die Kombination, d.h. es gibt mehrere Domänencontroller und meist „scheitert“ ab dem zweiten Domänencontroller die Ermittlung der richtigen Netzwerkkategorie nach dem Neustart (z.B. nach Windows Updates).

Der Vollständigkeit halber sei erwähnt, das die Domänencontroller nicht gleichzeitig, sondern der Reihe nach neu gestartet wurden und zudem immer gewartet wurde, bis der jeweils andere Server wieder vollständig gestartet war.

Mögliche Lösungswege

Bei verschiedenen Kunden haben verschiedene Methoden geholfen. Leider bislang immer nur in Verbindung mit einem Neustart.

I.d.R. genügt ein normaler Neustart. Als Schnellschuss, wenn der Server gerade nicht neu gestartet werden darf, kann es schonmal helfen die Netzwerkkategorie auf „Privates Netzwerk“ zu ändern (siehe hier), damit die meisten Dienste wieder normal erreichbar sind oder die Windows-Firewall vorübergehend zu deaktivieren.

Zuletzt, d.h. gestern, hat bei einem Kunden nur geholfen erst die Windows-Firewall für alle Kategorien zu deaktivieren und den Server neuzustarten. So wurde die Netzwerkkategorie richtig erkannt und die Firewall konnte wieder aktiviert werden.

Was bei manchen Kollegen der Lesart nach ebenfalls (ohne Neustart) geholfen haben soll wäre folgendes:

• Den Dienst „NLA (Network Location Awareness)“ (Dienstname: „NlaSvc“) neu starten.
• Via PowerShell die Netzwerkkategorie auf „Domänennetzwerk“ ändern:

  set-netconnectionprofile -interfaceindex <NR> -networkcategory DomainAuthenticated

Seit den Windows Updates vom November 2017 beobachten wir auf manchen Windows Server 2012 R2 Standard-Terminalserver, das keine RDP-Verbindungen aufgebaut werden können. Meist aber nicht ausschließlich tritt dies bei getrennten Sitzungen auf, die wiederhergestellt werden sollen.

Es kommen (sinngemäss) Meldungen wie „Terminaldienste ausgelastet“ oder es bleibt ewig bei „Willkommen“ oder „Windows wird vorbereitet“ stehen. Mitunter hilft es ein paar Minuten zu warten und dann die Verbindung erneut zu versuchen aufzubauen bzw. wiederherzustellen. Manchmal helfen nur weitere Massnahmen:

Als erstes und einfachstem (nach Warten) kann helfen den Benutzer vom Terminalserver abzumelden. Funktioniert diest nicht, kann man versuchen die entsprechenden Dienste „Remotedesktopdienste“ und „Anschlussumleitung für Remotedesktopdienst im Benutzermodus“ neu zu starten. Letzgenannter Dienst ist von „Remotedesktopdienste“ abhängig und wird über die Diensteverwaltung (wenn man die MMC/GUI) verwendet automatisch mit beendet und gestartet.

Achtung: Dabei werden alle aktiven Sitzungen getrennt!

Kommt man mittels Remotedesktopverbindung gar nicht mehr erst auf den Server (auch nicht als Admin), kann man die Dienste z.B. via psexec neu starten:

psexec \\<Server> -u admin -p cmd

net stop UmRdpService
net stop TermService

net start TermService

Mit dem Start von „TermService“ wird automatisch „UmRdpService“ mitgestartet.

Ob diese Schwierigkeiten evtl. mit den Windows Updates vom Dezember 2017 bereits behoben sind, kann aktuell noch nicht gesagt werden, da es bislang an Erfahrungswerten fehlt.