Alle Aktivitäten

Der Split-DNS wurde schon vor längerem eingerichtet. Der IIS wurde neu gestartet. Das Zertifikat ist "self signed", daher wurde die Hybrid-Konfig abgebrochen. Jetzt machen nur die Clients Probleme.

Die Änderungen im Split-DNS brauchen Zeit, kann man aber erzwingen Wenn du die URL am Exchange änderst, muss zwingend der IIS neu gestartet werden Ist das Zertifikat Self signed?

Vorher: HTTPS://servername.interne.domain/Autodiscover/Autodiscover.xml Geändert zu: HTTPS://mail.externe.domain/Autodiscover/Autodiscover.xml Aktuelle eingetragen URL: HTTPS://servername.interne.domain/Autodiscover/Autodiscover.xml Im Zertifikat steht, die interne und externe Domain drin. Ja, nur dieser eine Exchange (keine DAG), kein Loadbalancer, kein Reverse-Proxy im Einsatz, nur ein vorgeschalteter Spam-Filter. Im oben genannten Fall geht es um die Verbindung der Outlook-Clients von intern. MfG Meiner

Hi, welche URL wurde vorher genutzt, welche jetzt und was stand/steht alles im Zertifikat drin? Ist das nur dieser eine Exchange? Ist ein LoadBalancer / Reverse Proxy / irgendwas im Einsatz? Gruß Jan

Die URL wurde am Exchange geändert, zur Vorbereitung des Hybrid-Betriebs. Split-DNS ist eingerichtet und die URLs werden auch sauber aufgelöst. MfG Meiner

Warum und wo wurde die URL geändert? Nur am Exchange reicht nicht, das muss auch zum Eintrag im Split-DNS passen

Hallo Schwarmwissen, nach dem Ändern der Autodiscover-URL auf unserem Exchange öffnet sich bei ca. der Hälfte der User (ca. 1000) das Outlook nicht mit der Fehlermeldung "der Informationsspeicher steht nicht zur Verfügung". Nach dem die Autodiscover-URL wieder auf den Ursprungswert zurück geändert wurde, öffnet sich bei einer Vielzahl der User das Outlook mit der selben Fehlermeldung ebenfalls nicht. Workaround ist: - Ein neues Outlook Profil anlegen - Outlook mit altem Profil starten Lösche ich das neue Outlook Profil, startet das Outlook wieder nicht mit der Fehlermeldung "der Informationsspeicher steht nicht zur Verfügung". Was bewirkt das Anlagen eines neuen Profils, so dass das Outlook auch mit dem alten Profil startet? Ich möchte die ominöse Konfig auf alle betroffenen User ausbringen. Vielen Dank! MfG Meiner EDIT: Server: Exchange 2019 CU15 Client: Office 2021 LTSC

Dafür darf aber kein Programm im Fokus sein - sonst wird eben das geschlossen. 🤷🏼‍♂️

ALT + F4 den Usern beibringen, ja, das können die schon.

Hallo zusammen, ich habe auch einen der Kurse auf LinkedIn gemacht. War kurz, aber verständlich. Eignet sich gut, um einen Überblick zu bekommen, vor allem zu Begriffen und Konzepten. Für tiefere Anwendungen braucht man später wohl mehr. Finde aber gut, dass solche Angebote kostenlos sind. Schadet sicher nicht, mal reinzuschauen.

'n Tipp für einen möglichen Workaround ... Wenn die Abmeldung aus dem Startmenü wirklich nicht mehr möglich sein sollte, wäre es vielleicht eine Option einfach ein Desktop-Link anzulegen, der "shutdown.exe /L" aufruft. Das haben wir auf all unseren Servern mit GUI drauf. Diesen Desktop-Link erreicht man schneller und mit weniger Klicks als die Option im Startmenü. 🤷🏼‍♂️

Ich habe das jetzt mal so umgesetzt. Muss nur noch warten, bis mal eine entsprechende Mail ankommt, damit ich das nachvollziehen kann. ;)

LogOff Script exportiert die Registry Settings LogOn Script importiert die Registry Settings

Da es um Einstellungen von einzelnen Usern geht, die diese selbst in Programmen vornehmen können, ist die Vorgabe per GPO oder per Script keine Lösung. Wir haben auch keine Schwierigkeiten mit der momentanen Konstellation, da aber gut läuft. Es ging lediglich um die Frage, ob auch andere die gleiche Erfahrung gemacht haben, oder ob die Anmeldung auch bei der Konstellation wieder möglich ist, wie das bisher war. Trotzdem danke für die Ideen.

Seit Windows 8 (oder wars sogar 7?)tue ich mir servergespeicherte Profile nicht mehr an. Selbst Ordnerumleitung habe ich abgeschafft und durch simple Links auf Fileserver ersetzt. Wie das geht? User beeinflussen. Arbeitet mit dem Standard, rechnete jeden Tag mit einem neuen. Schieb die Schuld auf MS dass dies notwendig ist und jeder begreift es. Nicht vollständig fair, aber zweckmässig. Schau gleichzeitig, dass sich möglichst wenig ändert. Die User gewöhnten sich zu meinem erstaunen sehr schnell an diese arbeitsweise. Seither ist der Supportaufwand unglaublich tief geworden. Natürlich mache ich auch Anpassungen die müssen dann aber per Script oder GPO umsetzbar sein und sind so in der Regel auch Versionsresistent.

Der CU Bereich der Registry lässt sich doch recht easy per LogOn Script, geplantem Task und/oder Group Policy Preferences Registry anpassen.

Bei servergespeicherten Profilen geht es oft nicht anders.

Moin, 1. mit irgendeinem Server-Update wird es NICHT zusammenhängen 2. hast Du mal probiert, das Erscheinen das Startmenüs durch GPO zu *erzwingen*? Also praktisch "Remove Logoff on the Start Menu" auf DISABLED zu setzen?

Vor allem geht es da um den CU Bereich der Registry, in dem für einige Programme Einstellungen für den jeweiligen User gespeichert werden.

Oben schreibst du was anderes. Was wird denn in den Profilen _wirklich_ an Einstellungen / Konfiguration benötigt?

Es wird eine Kombination von Ordnerumleitung und servergespeicherten Benutzerprofilen genutzt, was auch ohne Probleme funktioniert und an den verschiedenen Arbeitsplätzen die gleiche Umgebung garantiert. Lokale Kopien von den servergespeicherten Profilen werden über die GPO gelöscht, was alles keine Probleme macht. Es geht also nur um die Änderung, die MS scheinbar vorgenommen hat, die jetzt das Abmelden über die GUI erschweren.

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen guten Dienstag, bleibt gesund! Noch ist es frisch bei nur 6°C, aber es wird ein schöner Tag bis etwa 21°C - Biergarten-Wetter Bin gut zurück von der Insel, neue Aufgaben

Hmm, warum bloß? Set-WmiInstance -Namespace root\microsoftDFS -Class DfsrMachineConfig -Arguments @{MaxOfflineTimeInDays = [uint32]101} oder $dfsrConfig = Get-WmiObject -Namespace root\microsoftDFS -Class DfsrMachineConfig $dfsrConfig.MaxOfflineTimeInDays = [uint32]99 $dfsrConfig.Put() oder das Gleiche mit Get-CIMInstance / Set-CIMInstance... ¯\_(ツ)_/¯

Hallo Freunde der Windows Server, ich sitze gerade an einem Problem in meinem Testnetz das ich schon ewig kenne - mich aber unter Server 2025 vor ungeahnte Probleme stellt: Es gibt kein WMIC mehr, und damit kann ich die DFS Replikation vom Sysvol nicht so anpassen wie ich mir das vorstelle... Frühe konnte man ja mit wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=?? den Wert für die maximale Offline Zeit zwischen DCs beeinflussen. In Produktivumgebungen tabu, gar keine Frage, nur bei Testnetzen die nicht immer laufen.... Jetzt war ich ne Weile krank und mein Testnetz war länger aus - schwups synchronisieren meine beiden DCs im Testnetz nicht mehr... Über autorisierende Wiederherstellung usw. habe ich das beheben können, soweit alles gut - nur wie macht man das denn wenn man - aus welchen Gründen auch immer - den Wert wirklich verändern muss??? Hat jemand eine funktionierende Idee? Ich such aktuell sehr erfolglos in der PowerShell rum. Grüße aus BaWü Norbert

@zahni wenn man das Profil nicht einfach durch Löschen des Verzeichnisses entsorgt, sondern über "supported methods", dann fliegt das automatisch mit weg. Ebenso wie alles unter HKLM, wo sich leider das App-Gedöns einnistet.