Alle Aktivitäten

Ich weiß nicht, ob der Restricted Admin Mode passend ist. Ich habe z. B. eine PAW. Die Rechner auf die ich mich verbinde folgen einem Tier-Modell, d. h. je nach Sicherheitsstufe und Funktion gibt es unterschiedliche User zur Verwaltung. Mit dem Restricted Admin Mode würde ich nun meinem regulären User mit dem ich mich auf der PAW anmelde überall Adminrechte geben, weil das auf SSO basiert. Ist das wirklich gut? Den Verwaltungsuser für die RDS-Bereitstellung in die Gruppe Protected Users zu schieben macht scheinbar keine Probleme. b***d, dass das bisher an mir durch ist. Ist das Standard für RDS Bereitstellungen?

Ich habe ihn mir zumindest angesehen. Allerdings möchte ich daran nicht herumstellen. Bzw. müsste ich das erst mit dem RZ besprechen, bevor ich auf dem Exchange sowas absetze. Aber ich meine, dass ich mich mit dem Supporter vom RZ gestern darüber unterhalten habe. Ich habe gefragt, warum dem Offlineadressbuch kein virtuelles Verzeichnis auf dem Exchange zugeordnet ist. Er meinte, dass das mit den virtuellen Verzeichnissen für das Offlineadressbuch hinfällig wäre, da er GlobalWebDistrubution aktiviert hätte. Kann es sein, dass dein Link mit dem Powershell-Befehl genau darauf rausläuft? Mal sehen, wie es weiter läuft damit. Der Support über das Microsoft365-Admin Center hat leider auch nicht helfen können und mich damit an eine weitere Supportadresse von Microsoft verwiesen. Spätestens da wird es jetzt dann hoffentlich irgendwie mit dem Problem weiter gehen.

Hast du den link von mir abgearbeitet?

Das hatte ich auch schon versucht. Der Fehler bleibt der Gleiche.

Denkfehler meinerseits. Die User sind tatsächlich auch bei mir über AD-Gruppen. Dann mache ich da tatsächlich kaum etwas an der Konfig.

Stimmt. ich würde mal ein neues Outlook Profil direkt ohne Cache-Mode probieren.

Stimmt auch wieder. Trotzdem muss das sauber veröffentlicht werden damit das klappt

Ist bei uns über AD-Gruppen gelöst.

Nee der greift in dem Fall auf die GAL zu, die üblicherweise im OAB enthalten ist.

Danke, der Inhalt vom Link scheint genau das Richtige zu sein. Schaue ich mir genauer an. Vielen Dank

"User hinzufügen, entfernen" wäre doch per AD Gruppe(n) regelbar, oder bin ich an der falschen Stelle? Mit den OUs könnte so gemacht werden oder auch mit einer leeren AD Gruppe, die in den lokalen Administratoren der beteiligten Server ist und bei Bedarf packst du "dich" da rein. Aber hier dürfte es auch noch weitere Wege geben. BTW.: Damit die Credentials nicht "auf dem Gateway" oder woanders liegen -> Protected Users / Restricted Admin Mode: NLA + RDP SSO + RDGW + Restricted Admin Mode + Protected Users group = True | Secure Identity

Habe ich noch nicht darüber nachgedacht. Im laufenden Betrieb tatsächlich nur die Sammlungen (User hinzufügen, entfernen) und das so 2 - 3 x im Monat. D. h. Deine Überlegung wäre in die Richtung, dass ich evtl. zwei OUs habe, in einer werden die User als Admins hinzugefügt und in einer anderen entfernt und ich verschiebe die VMs dann je nach Bedarf hin und her?

Hi, eine Frage wäre, wie oft "administrierst" du tatsächlich Dinge in der Farm und was wäre das? (Im laufenden Betrieb stört sich die Bereitstellung ja nicht daran, wenn der / die User (theoretisch) gar keine Rechte auf den Systemen haben.) Gruß Jan

Hallo und guten Morgen, ich bin mir unsicher, wie ich folgendes Szenario beurteilen soll: Es gibt eine RDS-Bereitstellung mit Broker, Gateway und Session-Hosts. Auf dem Server mit dem Broker wird die Bereitstellung verwaltet. D. h. da sind im Servermanager alle Server der Bereitstellung hinzugefügt. Das Gateway ist in einem separaten Netzwerksegment. Ein Session-Host ist ebenfalls in einem separaten VLAN, weil dieser von den Nutzern her einem besonderen Kompromittierungsrisiko ausgesetzt ist. Das alles funktioniert, die Firewall-Regeln sind entsprechend gesetzt. Um die Bereitstellung zu verwalten gibt es einen User, der auf allen beteiligten Servern Adminrechte haben muss. Und genau da bin ich mir nun nicht sicher, ob das ein Risiko ist, weil es so einen Benutzer gibt, der über die VLANs hinweg Adminrechte hat und die Anmeldung auch über die VLANs hinweg genutzt wird. Damit eine solche Bereitstellung funktioniert müssen folgende Freigaben konfiguriert werden: WinRM: Broker -> Gateway, Session-Hosts RPC: Broker -> Gateway, Session-Hosts RPC: Session-Hosts -> Broker RDP: Gateway -> Session-Hosts, Broker Port 5504: Gateway -> Broker (WebAccess) Also, sollte das Gateway kompromittiert werden und die Zugangsdaten herausgefunden werden, kann man sich vom Gateway aus per RDP mit dem Broker und allen Session-Hosts verbinden und die meisten Session-Hosts stehen im allgemeinen LAN und sind nicht separiert. Habe ich einen Denkfehler oder gibt es da eine Art "best practices"? Ergänzung Lt. früheren Tests, kann man das Passwort im Klartext mit Mimikatz auslesen, wenn man sich interaktiv (per RDP) an einem Server anmeldet. Erfolgt die Anmeldung per WinRM sollte (Theorie) nur das Ticket/Hash ausgelesen werden können. D. h. ich müsste dann nur dafür sorgen, dass der Verwaltungsuser zwar Adminrechte überall hat, aber mich mit diesem niemals per RDP anmelden? Liege ich da falsch? Vielen Dank

Ok... danke für die Info. Das Aktualisieren des Adressbuchs auf dem Server hat leider keinen Erfolg gebracht. Der Befehl wird ohne Fehlermeldung in der Powershell verarbeitet. Der OnPremise ist laut Management-Shell Version 15.2 (Build 1748.10). Es ist ein Exchange 2019, wahrscheinlich mit CU15 vom 10. Februar 2025. Er wird vom RZ betrieben und gewartet.

Im Online-Mode, also ohne Cache muss der Client auf das OAB vom Server zugreifen Klappt das nicht, kommt o.g. Fehlermeldung

Danke dir für deine Antwort. Sollte denn das Offline-Adressbuch von Outlook überhaupt werden benutzt bei deaktiviertem Exchange Cache-Modus? Wie soll das denn gehen? Man hat ja nicht einmal eine Schaltfläche zum herunterladen? Mir wurde das so erklärt, dass das Offline-Adressbuch nur eine Kopie der globalen Adressliste ist. Bzw. war die Aussage vom RZ-Support, dass eigentlich auf die globale Adressliste zugegriffen werden sollte. Das Offline-Adressbuch funktioniert auch, mit aktiviertem Cache-Modus.

Moin, erst mal an einer Exchange shell schauen, ob es ein OAB gibt Get-OfflineAddressBook Dann mal prüfen, ob ein Update möglich ist Update-OfflineAddressBook Und schau mal hier: https://community.spiceworks.com/t/exchange-server-2016-offline-address-book-client-office-2016/800824/2 Ist zwar älter passt aber im wesetlichen... Nachtrag - welchen Stand hat der On-Premises?

Guten Morgen, ich habe ein Problem, bei dem ich wahrscheinlich auch den Microsoft-Support kontaktieren werde. Aber vielleicht hat hier jemand das Phänomen schon einmal gesehen. Wir betreiben eine Exchange-Hybridbereitstellung, bestehend aus Exchange-Online und einem OnPremise-Exchange in einem RZ. Mit dem RZ-Support habe ich das Thema schon besprochen. Die sind im Moment etwas ratlos und meinen das dürfte gar nicht so sein. Problem scheint jedenfalls zu sein, dass der Outlook-Client (Outlook 2016 und Outlook 365) ein Problem mit dem globalen Adressbuch für Postfächer auf dem OnPremise-Exchange hat. Sobald der Exchange-Cache Modus deaktiviert ist, kommt folgende Fehlermeldung in Outlook beim Öffnen des Adressbuchs: Eigentlich dürfte bei deaktiviertem Cache-Modus gar nicht versucht werden ein Offlineadressbuch abzurufen. Der Fehler tritt scheinbar nur bei OnPremise-Postfächern im Outlook-Client (2016 und 365) auf. Das Adressbuch funktioniert mit aktiviertem Cache-Modus normal. Hat hier jemand eine Idee, wo da der Fehler sein könnte? Viele Grüße Outcast

Enkelin hat in der Kita übernachtet, die holen wir gleich ab - bin gespannt...

Man bist du heute zeitig.

Moin an Board, so starten wir dann in den Tag - ich koche Kaffee Allen einen stressfreien Freitag, bleibt gesund! Hier hat es die Nacht geregnet, im Moment trocken bei 16°C, ab etwa 9:00h wieder Regen bis Mittag Es wird wohl bis 21°C am Nachmittag und es bleibt den ganzen Tag bedeckt

Dann nutze doch mal die Such/Filterfunktion von GPEdit (Rechtsklick auf "Administrative Vorlagen", Du wirst es finden).

Hi TP das sind alles Systeme auf demselben Host. Die Hardware zeigt keine Fehler, nur in der USV sind Akkus defekt. Der hyperV hat aber 2 Netzteile, einmal USV, einmal Strom. BackupRestore vom selben Tag bringt den gleichen Fehler BackupRestore von gestern läuft ... Was kann so ein Verhalten auslösen?

Hi, sind das alles VMs auf dem gleichen Host / im gleichen Cluster oder sind das komplett verschiedene (Kunden) Systeme / Umgebungen? Gruß Jan