Alle Aktivitäten

Für's nächste Mal: Ein vollständiges Event wäre in solchen Fällen immer hilfreich, da gibt's relativ viele Felder mit Status- und Errorcodes.

Mach nen Batch-Wrapper, der vorher per cmdkey /delete den Server aus den Anmeldeinformationen entfernt. Dann kommt immer die Abfrage mit Kennwort und Benutzer. Sonst kommt immer nur die Abfrage mit Kennwort. Ich gehe mal davon aus, daß Du von einer shared Workstation redest, wo ein technischer User angemeldet ist und dann die RDP-Verbindung mit dem tatsächlichen User erfolgen soll. Da wäre auch noch möglich (siehe oben) einen Wrapper drum rum zu bauen, der User-ID und Kennwort abfragt und per cmdkey /add in die Anmeldeninformationen schreibt. Und danach halt wieder entfernt. Am Ende wird es auf einen Trick rauslaufen, der mit Get-Credential und cmdkey.exe Dinge zaubert

Hi, dass hatten wir auch und kann mit exchange zero config erledigt werden. https://learn.microsoft.com/de-de/microsoft-365-apps/outlook/profiles-and-accounts/zeroconfigexchange Grüße

Hi, mir ist bei einem Kunden die Event Id 6167 aus der Quelle "LSA (LsaSrv)" im Eventlog recht hartnäckig um die Ohren geflogen. Eine kurze Google Suche hatte dann diesen Beitrag hervorgezaubert. Gruß Jan

Hallo Jan, danke das klingt exakt nach unserem Problem! Wie bist Du auf diesen Thread gestoßen?

Ohne das getestet zu haben. https://znil.net/index.php/Batch_RDP_Verbindung_starten_mit_Benutzername_und_Passwort Das könnte man mit einem Powershell-Dialog zur Abfrage von User/Password kapseln...

Hi, den Anmeldevorgang auf den lokalen Client "auslagern" und per SSOn auf den Terminalserver verbinden? Evtl. findet sich auch was aus der Richtung "Transformer" aus dem Citrix WEM oder man versucht das mit Bordmitteln / Kiosk nachzuahmen. Gruß Jan

Wenn Du auf NLA verzichten kannst, kannst Du die Anmeldung direkt am Anmeldebildschirm des Terminalservers durchführen. Das geht mit mstsc, musst halt die .RDP Datei ein wenig pimpen. Die beste Lösung für sowas sind Smartcards. Gesteckt --> Anmeldung, gezogen --> Abmeldung

Hallo zusammen Auf Clients mit Windows 11 soll eine RDP-Verbindung zu einem Server aufgebaut werden können. Die Benutzer wechseln häufig und sind keine geübten Anwender (Pflegepersonal). Sie sitzen jeweils nur für wenige Minuten am Rechner und trennen dann die Verbindung. Nach fünf Minuten Inaktivität wird die Verbindung vom Server getrennt. Sie sollen ihren Benutzernamen und ihr Passwort eingeben können. Um die Domäne sollen sie sich nicht kümmern müssen. Das Kennwort dürfen sie auf keinen Fall speichern. Der zuletzt verwendete Benutzername darf hingegen erhalten bleiben. Mit mstsc.exe ist das Ändern des Benutzernamens umständlich und man muss die Domäne angeben. Kennt jemand eine solche Anwendung? Ich stelle mir etwas vor, wie man es von Thin Clients her kennt. Wichtig: Funktionen wie umgeleitete Drucker und Laufwerke müssen vorhanden sein. Am liebsten wäre mir ein Wrapper um den originalen Client. Besten Dank für eure Tipps!

Hi, ich würde darauf tippen, dass es genügt Autodiscover sauber zu konfigurieren und zusätzlich ggfs. per GPO am Client einzuschränken: GPS: AutoErmittlung deaktivieren Gruß Jan

Moin, ich habe einen neuen Client mit Office 2024 installiert. Die derzeitigen Clients laufen noch mit Outlook 2016. Jetzt wollte ich den neuen Client mit dem Exchange 2016 verbinden. Starte ich Outlook wird mir zuerst die richige E-Mailadresse angezeigt. Klicke ich dann auf Verbinden, schlägt Outlook mir ein IMAP-Konto vor, welches nicht existiert. IMAP läuft nicht auf dem Exchange. Klicke ich jedoch auf die erweiterte Option und wähle dort Exchange aus, dann wird das Konto ordnungsgemäß eingerichtet. Gibt es noch eine Möglichkeit, dass Outlook das Konto gleich im ersten Schritt unter "Verbinden" eingerichten kann? Anbei die Screenshots.

da hab ich mich nur vertippt - die Syntax war richtig

Das kannst du so argumentieren und handhaben. Wie viel Arbeit ist es aber, das "kurz" in ein GPO zu packen und auf alle Systeme auszurollen? Lohnt es da "groß zu diskutieren" bzw. Energie in die Abwägung zu stecken?

Hi, oder auch: Kein RDP oder File Share mehr nach letzten Windows Update (LSA(LsaSrv) Event ID 6167) - Microsoft Q&A Es findet sich zum September Patchday unter Server 2025 / Win 11 24H2 recht viel in diese Richtung. Gruß Jan

Hast du evtl. das SMBv1 Problem was mit den September Updates mal wieder da ist? Nur als Idee Windows 10/11: September 2025-Updates verursachen SMBv1-ProblemeBorns IT- und Windows-Blog

Moin, ich wollte nicht in Abrede stellen, dass deine Gründe valide sind. Und als ich meinte, du musst die angehen - erstens weißt du das ja, und zweitens ist auch klar, dass das nicht so einfach in deiner Macht liegt. Davon solltest du dich aber nicht hindern lassen, den Teil, den du kontrollieren kannst, für dich sinnvoll zu bauen. Das eine tun, ohne das andere zu lassen. Ich rate dabei aber, nicht zu viel auf einmal zu wollen. Sonst wirst du nie fertig, und du baust dir deine eigene Überforderung. IT-Sicherheit kann man immer noch mal besser machen, aber genau das ist der Punkt: Es ist ein Prozess. Mach Dinge Schritt für Schritt. Viele Risiken, die es grundsätzlich gibt, sind in einer konkreten Situation gar nicht relevant oder recht unwahrscheinlich, die muss man dann auch nicht im ersten Schritt ausschalten. Nein, würde man nicht. Das sind unterschiedliche Netze. Die Hosts haben ein eigenes Betriebssystem und einen eigenen Netzwerkstack, der mit denen der VMs nichts zu tun hat. Da das in Hyper-V leider nicht besonders übersichtlich gebaut ist und da auch viele Internet-Quellen das nicht gut darstellen, hab ich das mal selbst beschrieben. Das ist im Detail zwar nicht mehr ganz aktuell, die Grundzüge sind aber noch dieselben. [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Finde den Fehler. Du verheimlichst uns was. ;) Kopier das doch einfach vollständig aus der Exchange Shell raus, mit Prompt zu Beginn und am Ende.

Hi, 2x Windows 1124H2 mit aktuellen Updates. Auf einem PC ist das Datenlaufwerk via "D%" freigegeben! Seit einem der letzte MS Updates funktioniert der SMB Zugriff vom anderen PC nicht mehr! Auf beiden Systemen befindet sich ein gleichnamiges Benutzerkonto (mit Adminrechten) und auch die Kennwörter sind identisch! Das Security Eventlog wirft folgendes aus: Bei der Anmeldung ist ein Fehler aufgetreten (Ereignis-ID: 4625)! Diese ID sieht man auch, wenn man ein falsches Kennwort eingibt, allerdings ist dann der Fehlertext ein anderer (Benutzername oder Kennwort falsch)! Was wir schon alles probiert haben: - Die Anmeldeinformationsverwaltung geleert und beide Systeme neugestartet - Die Verbindung über andere Accounts (z.B. den integrierten Administrator) probiert - Verschiedene Schreibweisen ausprobiert (\\smbserver_hostname\username) oder (\\smbserver_ip\username) oder auch nur (username) - Eine neue sichtbare Freigabe erstellt - Insecure Guest Logins erlaubt (https://learn.microsoft.com/en-us/answers/questions/2189515/windows-11-24h2-and-insecure-guest-logins-settings?forum=windowsclient-all&referrer=answers) Fällt sonst noch Jemandem etwas dazu ein, oder muss man da jetzt mit Wireshark ran? Danke!

Da gebe ich dir ja absolut recht, aber wie soll man sowas lösen? Ich habe zum Thema "Rechenzentrum" schon Dinge mitbekommen, die darf man niemandem erzählen... Zumindest mich hat die Geschichte mit Südwestfalen-IT kein bisschen erstaunt, es wundert mich eher dass da nicht noch mehr kam in letzter Zeit. Wenn ich den Admin Approval Mode für den Built-In Admin aktivieren würde, wäre Veeam ja nicht mehr in der Lage sich am Hyper-V-Host anzumelden. Wie gesagt, Veeam außerhalb Domäne = entweder Built-In Admin oder UAC deaktivieren. Ist b***d, aber laut Veeam nicht zu ändern. Scheint auf jeden Fall zu funktionieren, habe mal ne Deny-All Inbound am Hyper-V-Host für eine Client-IP erstellt. Zugriff war vom entsprechenden Client auf den Hyper-V-Host nicht mehr möglich. Aber warum sollte ich das ganze auf den restlichen System umgekehrt auch implementieren? Wer erfolgreich am Hyper-V-Host ist kann ohne Probleme auf alle Server-VM's zugreifen, da hilft die Firewallregel nichts. Die einzigen Server bei denen das Sinn machen würde wären doch höchstens der Veeam Server und der physische DC? Oder habe ich da einen Denkfehler?

OK, ich kann die Gründe durchaus nachvollziehen, aber die Lösung kann dann doch nicht sein, das nächste "suboptimale" Konstrukt in Betrieb zu nehmen. Aber jeder wie er mag.

Klingt schon mal nach ner Idee... Also auf den Hyper-V-Hosts Deny für alle IP-Adressen der Hosts und Clients, abgesehen vom Backup-Server und dem Backup-Proxy... Aber würde ich damit dann nicht nur das Management-Netz der Hyper-V-Hosts beschränken, sondern auch das VM-Netz? Das wäre natürlich dann ziemlich b***d Wäre natürlich auch recht Wartungsintensiv in Sachen neue Hosts/Clients, je nach IP Range.

An der Stelle könnte man darüber nachdenken, an den Hyper-V Hosts - losgelöst ob Domain / Workgroup - per Windows Firewall eine Deny In- / Outbound Regel zu erstellen, die eben die IP Range(s) der Workloads / restlichen Systeme abdeckt. Auf den restlichen Systemen wird das Ruleset dann einfach "umgekehrt" implementiert. Zwischen Hyper-V Hosts und Veeam Server bzw. ggfs. zwischen Veema Server und Workloads müsstest du dann etwas granularer rangehen. Bzw. auch wenn die Hosts in der Domain sind.

Die "Gründe" sind einfach; wir hängen an einem Rechenzentrum das die Firewall und das damit verbundene Routing kontrolliert. Da komme ich nicht dran. Leider reicht auch mein Know-How nicht aus, um z.B. einfach mal noch ne zweite Firewall "davor" zu setzen im Produktivnetz. Und Hilfe darf man da leider nicht erwarten, da ist Personal dünn gesät und gutes erst recht... Ich muss also erstmal mit dem klar kommen was ich habe und was ich beeinflussen kann.

Moin, wenn du schon auf der Ebene nachdenkst und argumentierst - was sinnvoll ist -, dann solltest du in Betracht ziehen, einen separaten Infrastruktur-Forest für deine Host-Umgebung einzurichten. Dort hast du dann die Vorteile der Domänenverwaltung und kannst die Domäne getrennt von deiner Produktionsdomäne absichern. Sollte es dort dann ein Problem geben, ist der andere Forest nicht automatisch mit korrumpiert. Ich stimme aber auch Jan zu - das Niveau, das du erreichen willst, ist mit den "Gründen", die du nebulös anführst, nicht vereinbar. An die wirst du auch ran müssen. Gruß, Nils

Hi, ich würde - losgelöst von Workgroup / Domain - ASAP "Gründe" beseitigen. Die Frage wäre, ob man den Admin Approval Mode nicht generell auch für den Built-In Admin aktiviert (User Account Control Admin Approval Mode for the Built-in Administrator account - Windows 10 | Microsoft Learn). Gruß Jan