dataKEKS

Also: SSH und SFTP mit einem Windows Server sind gar kein Problem, sowohl mit der von Microsoft direkt mitgelieferten Version beim Windows Server 2025 als auch bei den Vorgängern (und da als optionales Feature).
 
Ich versuche nicht einen kompletten Roman zu schreiben sondern nur ein paar wichtige Stichworte:
- Egal ob Server 2025 oder älter, die Einrichtung aktiviert nicht beide Dienste die zur Key-based authentication erforderlich sind, ebenso wenig passt die Firewall Regel so der Server Mitglied einer Domäne ist,
 
# OpenSSH SSH Server als auf Startart automatisch setzen und starten
Get-Service -Name sshd | Set-Service -StartupType Automatic
Start-Service sshd
# OpenSSH Authentication Agent als auf Startart automatisch setzen und starten
Get-Service ssh-agent | Set-Service -StartupType Automatic
Start-Service ssh-agent
# Firewall so anpassen das nur dann Verbindungen möglich sind wenn die Firewall des Servers im Domänenprofil ist
Set-NetFirewallRule -Name OpenSSH-Server-In-TCP -Enabled True -Profile Domain
 
Damit ist vom Server alles fertig, alles andere sind Einstellungen (sshd_config unter %programdata%\ssh), Filesystem Rechte für die Benutzer und Keys.
 
Was super funktioniert und genau mein Thema seitens der Rechte sauber abbildet: Es gibt die Möglichkeit mit zwei Zeilen die Rechte pro Benutzer sauber einzuschränken:
Match User %domain%\%username%
ChrootDirectory "%drive%\%path%"
 
Das pro User eingetragen (und danach den Dienst gestartet für dazu das der User nicht mehr unter c:\users\%username% landet sondern in dem zuvor definierten Pfad und von da aus nur in Unterordner, nicht aber in die übergeordneten Laufwerke. Wichtig hierbei natürlich: Der Benutzer sollte auch Schreibrechte in dem Pfad haben wenn er Uploads durchführen soll..
 
Noch zwei ganz wichtige Anmerkungen:
- die sshd_config ist Case Sensitiv, als Groß- und Kleinschreibung beachten, und Änderungen an ihr werden erst mit Neustart vom Dienst sshd übernommen
- per Default können sich nur Administratoren verbinden, wenn es wie in meinem Fall bewusst mit normalen Benutzern laufen soll braucht man dazu mindestens eine Gruppe, diese wird beim Server 2025 zwar angelegt, nur bei einer deutschsprachigen Version leider eingedeutscht während die Konfiguration vom OpenSSH Server den originalen, englischen Namen verwendet. Ihr könnt hier sowohl die Gruppe umbenennen oder die Konfiguration anpassen, nur eins von beidem ist dann halt doch zwingend erforderlich....
 
Wie vermutlich jedem von uns ist mir bei diesem Thema eins sehr leidvoll aufgefallen: Viele Anleitungen geben nur Bruchstücke wieder, und die übersetzten Artikel sind immer wieder stark "verzerrt" und damit teilweise falsch, also wenn ihr sucht: Kämpft euch besser durch das englische Original, es schont die Nerven!
 
Norbert

Sodele, jetzt konnte ich mich endlich dem Thema wieder widmen und kann folgendes berichten:
 
Da ein Neustart unseres Haupt-Hyper-V im Tagesbetrieb bei den Usern nicht so toll ankommt habe ich die VMs auf einen kleineren, eigentlich nicht mehr benutzten Testserver ausgelagert, einen HPE MicroServer
 
Egal ob ich ihn mit Server 2022 oder 2025 betreibe, die problematischen VMs haben das Problem nach Export auf dem eigentlichen und Import auf dem Testserver beibehalten, das spricht sehr für die Vermutung das wirklich in der Konfiguration ein Fehler steckt und nicht der ausführende Hyper-V das Problem ist.
 
Somit war klar: Jetzt bekommen die beiden problematischen VMs mal eine neue Konfiguration, also VM im Hyper-V gelöscht, neu angelegt und dann die VHDs wieder eingebunden, LAN Konfiguration passend definiert (bei uns VLANs) und die VMs gestartet - funktioniert. Was nur quasi zu erwarten war: Für Windows sind es neue NICs, und damit musste ich noch die statische IP Adresse wieder eintragen. Werde das gleiche noch einmal probieren und vor dem Start der VMs noch die alte MAC Adresse händisch hinterlegen, aber das nur am Rande.
 
Jetzt zum spannenden Teil: Neustart des Hyper-V ohne die VMs vorher herunter zu fahren: Es tut wieder, die VMs können problemlos wiederhergestellt werden ohne irgendeine Änderung am ausführenden Hyper-V
 
Somit wissen wir jetzt schon einmal wie wir das Problem lösen können, wenn jetzt noch die NIC im Zuge der Neuanlage im Hyper-V nicht neu erkannt wird wäre das natürlich noch eine enorme Erleichterung
 
Update folgt.
 
 
Norbert

Also ich kenne diese Thematik mit verschiedenen Herstellern immer nach dem gleichen Prinzip:
 
- Du fährst zwar zwei VLANs auf einem Switchport aber nicht beide getagged sondern das Client VLAN untagged und zusätzlich das Telefon VLAN tagged
- Dann richtest Du Dein IP Telefon so ein das es tagged mit dem VLAN der TK kommuniziert
- Am zweiten LAN Port des Telefons kommt untagged das VLAN für den Client an der somit in seinem VLAN kommuniziert und nichts vom Telefon VLAN mitbekommt.
 
Hilft diese Erklärung?
Norbert (der andere)

Leute, ihr glaubt es nicht!
 
Wir haben wirklich alles richtig gemacht bei der Migration, die Quelle der Probleme lag leider wie so oft komplett wo anders...
 
Auch wenn ich euch technisch leider nicht wirklich die Ursache erklären kann, die NTDS.dit auf dem Quellserver (das war mal ne Zweiserver Umgebung mit DC + MSX + + + auf der einen Maschine sowie ein TS) wurde mittlerweile eine sauber aufgeteilte Umgebung mit einem reinen Exchange Server, aber das ändert natürlich nichts mehr am Verhalten des alten Exchange.
 
Ja, mit Eventlog prüfen in allen Unterbereichen hätte es mir auch früher auffallen können, ich wurde stutzig als mir der Quellserver in der Powershell noch Postfächer für die Datenbank angezeigt hat die schon migriert waren und so kam ich dann eben erst auf die Idee mal wieder ins Eventlog zu sehen...
 
Fehlerbild waren diverse Fehlermeldungen, angefangen bei NTDS (696) NTDSA: Datenbank C:\Windows\NTDS\ntds.dit: Index DRA_USN_index von Tabelle datatable ist beschädigt (0).
 
Noch detailierter wurde es hier:
 
Dieses Ereignis enthält Reparaturvorgänge für das Ereignis "1084", das zuvor protokolliert wurde. Diese Meldung deutet auf ein bestimmtes Problem in Bezug auf die Konsistenz der Active Directory-Domänendienste-Datenbank für dieses Replikationsziel hin. Bei der Übernahme von Replikationsänderungen für das folgende Objekt ist ein Datenbankfehler aufgetreten. Die Datenbank enthält nicht erwartete Inhalte, die verhindern, dass die Änderung durchgeführt wird.   Objekt: CN=Ruiter Tanja,OU=Lehrer,OU=Benutzer,.............. Objekt-GUID: 203ca1ec-0077-4aee-ba28-d3779e42b61a  Quell-DC: db2753ff-5192-4b96-867e-c998ef49e18e._msdcs...........   Benutzeraktion    Weitere Informationen finden Sie im KB-Artikel 837932 unter "http://support.microsoft.com/?id=837932".Ein Teil der Reparaturvorgänge ist dort aufgelistet.  1. Stellen Sie sicher, dass genügend freier Speicherplatz auf den Volumes vorhanden ist, auf denen die Directory-Datenbank gehostet wird, und wiederholen Sie den Vorgang. Stellen Sie sicher, dass sich die physikalischen Laufwerke, auf denen NTDS.DIT und die Protokolldateien gehostet werden, nicht auf Laufwerke befinden, auf denen NTFS-Komprimierung aktiviert ist. Prüfen Sie, ob Antivirussoftware auf diese Volumes zugreift.  2. Es ist eventuell vorteilhaft, wenn der Sicherheitsbeschreibungspropagierer gezwungen wird, die Objektcontainerherkunft in der Datenbank erneut zu erstellen. Dies kann entsprechend den Anweisungen im KB-Artikel 251343 unter "http://support.microsoft.com/?id=251343"durchgeführt werden.  3. Das Problem kann ggf. auch beim übergeordneten Objekt auf diesem Domänencontroller auftreten. Verschieben Sie das Objekt auf dem Quell-DC zu einem anderen übergeordneten Objekt.  4. Wenn dieser Computer ein globaler Katalog ist und der Fehler in einer der schreibgeschützten Partitionen auftritt, sollten Sie den Computer als globalen Katalog über das Kontrollkästchen "Globaler Katalog" in der Anwendung "Standorte und Dienste" herabstufen. Wenn der Fehler auf einer Anwendungspartition auftritt, können Sie das Hosten der Anwendungspartition auf diesem Replikat beenden. Dies kann mit dem Befehl NTDSUTIL.EXE durchgeführt werden.  5. Beziehen die neueste Version von NTDSUTIL.EXE, indem Sie das neueste Service Pack für dieses Betriebssystem installieren. Stellen Sie sicher, dass das DSRM-Kennwort (Directory Services Restore Mode) bekannt ist, bevor Sie den DSRM-Modus starten. Setzen Sie es andernfalls zurück, bevor Sie das System neu starten.  6. Führen Sie unter einer NT-Eingabeaufforderung im DSRM den Befehl "NTDSUTIL files integrity" aus. Stufen Sie das Replikat herab und überprüfen Sie die Hardware, wenn eine Beschädigung gefunden wurde und andere Replikate vorhanden sind. Stellen Sie das System über eine Sicherung wieder her, und wiederholen Sie diese Verifizierung, wenn keine Replikate vorhanden sind.  7. Führen Sie eine Offlinedefragmentierung mit dem Befehl "NTDSUTIL files compact" aus.  8. Der Befehl "NTDSUTIL semantic database analysis" sollte ebenfalls ausgeführt werden. Wenn Fehler gefunden wurden, können diese mit der Funktion "go fixup" behoben werden. Dies sollte nicht mit der Datenbankwartungsfunktion "ESE repair", die in diesem Fall nicht verwendet werden sollte, verwechselt werden, da dies zu Datenverlust bei der Active Directory-Domänendienste-Datenbank führt.    Wenn keine dieser Aktionen erfolgreich ist und der Replikationsfehler weiterhin auftritt, sollten Sie diesen Domänencontroller herab- und anschließend wieder heraufstufen.    Zusätzliche Daten  Primärer Fehlerwert: 8451 Der Replikationsvorgang ist auf einen Datenbankfehler gestoßen.  Sekundärer Fehlerwert: -1414 JET_errSecondaryIndexCorrupted, Secondary index is corrupt. The database must be defragmented  
Die Lösung war trotz Bauchweh erstaunlich einfach: Server im Verzeichnisdienst Wiederherstellungsmodus starten, mit ESEUTIL die DB defragmentieren und nach einem Neustart und ein paar Minuten warten war das komplette Active Directory endlich wieder sauber und die Exchange Migration lief vollends sauber durch.
 
Lange Suche - Kurze Lösung: AD Replikation bei Exchange Migrationen im Auge behalten!

Hallo Nils, Hallo Norbert!
 
War wirklich nur ein AD, kein Witz. 
 
Der Tip über die Powershell wie in Frank von der MSX FAQ gelistet hat war die Lösung.
 
# Linked mailbox in usermailbox verwandeln
[PS] C:\>set-user user1 -LinkedMasterAccount $null'
 
Ich danke euch, war mal wieder mit Blindheit geschlagen :-)
 
Gruß
Norbert

ARG
 
Ich glaub es nicht! Fehlersuche in der IT, eine Wissenschaft für sich!
 
Norbert hat mich in die richtige Richtung geschoben durch seine verdeckten Hinweise Richtung Autodiscover. Nach Tagen der Grübelei und eben seinen Andeutungen habe ich wohl oder über mal das Tracing per Whireshark bemüht und was sahen meine müden Äuglein da: Der Client hat bei meinem User die direkte Kommunikation Richtung Exchange gesucht, nur bei den Sorgenkindern über einen Proxy???
 
Also in den GPOs gegraben und den Unterschied endlich gefunden: Die User die Probleme machen gehen über einen Proxy, die User die funktionieren.....
 
Kleine Ursache - große Wirkung!
 
Jetzt vergrabe ich mich mal in den GPOs und wie ich das beheben kann, die Proxy GPO kommt nämlich noch aus der Server 2003 Zeit und arbeitet im IE Voreinstellungsmodus weswegen ich sie nicht mehr bearbeiten kann....

Hey Sunny!
 
Kein SFTP, das kann der IIS soweit ich es verstanden habe nicht, er kann "nur" FTP mit SSL
 
https://serverfault.com/questions/648855/is-iis-sftp-natively-supported-by-windows-server-2012-r2
 
Gruß
Norbert

Leute!!!
 
Ihr werdet es nicht glauben! Es ist wie so oft - richtig gemacht und funktioniert trotzdem erst mal nicht! Nach langem suchen (sitze seit heute Mittag an dem Thema) bin ich gerade über diesen Artikel gestolpert: http://grantcurell.com/2013/12/31/failed-to-retrieve-directory-listing-filezilla-connecting-to-iis-behind-nat/
 
Da steht etwas zum Haare raufen: Den FTP Dienst nicht im IIS neu starten sondern über die Dienstesteuerung, das ist NICHT das gleiche!
 
Kaum machte ich es über services.msc.....
 
Sollte also noch mal jemand suchen, es funktioniert jetzt sauber und ich kann SSL erzwingen womit Klartext der Geschichte angehört :-)
 
 
Geschaffte aber glückliche Grüße
Norbert

Hallo Kollegen!
 
Sachen gibt´s - die gibt´s gar nicht. Nachdem noch mehr nicht löschbare Dateien aufgetaucht sind haben wir den Server mit einem CHKDSK /f mal das Laufwerk C: detailiert prüfen lassen und siehe da - wir können wieder den Besitz übernehmen und die Daten / Ordner löschen. War also das Dateisystem fehlerhaft und nicht der Weg wie es versucht wurde :-)
 
 
Norbert