Alle Aktivitäten

Moin, also eigentlich etwas einfaches Man müsste jetzt schauen, warum das so war Üblich ist das nicht Aber danke für die Rückmeldung!

Der RZ-Support hat das Problem zusammen mit Microsoft gelöst bekommen. Es lag wohl an dem AppPool "MSExchangeMapiAddressBookAppPool". Der musste auf dem OnPremise-Exchange neu gestartet werden. Seitdem funktioniert wieder alles normal. Danke für eure Unterstützung.

Tach an Board, heute länger geschlafen, bei uns war gestern Stadtteil-Fest Allen einen guten Start in die Woche und den letzten Montag im Monat - Zack ist ein halbes Jahr vorbei! Ich koche noch eine kleine Kanne Kaffee, Wasser usw. stehen auch bereit Hier sonnig bei18°C, es werden so bei 26°C ☀️ Bleibt gesund! 😎

und falls du doch zu faul bist: Computerkonfiguration → Administrative Vorlagen → Google → Google Chrome → Performance Computerkonfiguration → Administrative Vorlagen → Google → Google Chrome → Performance Enable Battery Saver Mode (Batteriesparmodus aktivieren) Wert sezen auf: Deaktiviert Enable Memory Saver Mode (Speichersparmodus aktivieren) Wert setzen auf: Deaktiviert oder: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome] "BatterySaverModeEnabled"=dword:00000000 "MemorySaverModeEnabled"=dword:00000000

Hi, du könntest testweise für ein paar Stunden im Admin Center den MAPI Zugriff abschalten und im Anschluss wieder aktivieren. Ansonsten hilft bei vielen kuriosen Dingen auch bei Exchange online ein Mailbox Move (New-MoveRequest (ExchangePowerShell) | Microsoft Learn). (Auch wenn Microsoft das nicht "möchte".): Gruß Jan

Ja, mehrmals nur mit dem Support von MS zu lösen gewesen Ggf. mehrfach eskalieren Letztes Mal in zwei Tagen erledigt

Hi, Das habe ich parallel bereits getan, allerdings die Vermutung, dass hier wieder Tage und Wochen ins Land gehen werden, bis von da eine brauchbare Information oder Lösung kommt. Daher auch die Frage hier, ob das Problem schon mal jemand hatte. Grüße!

Mache ein Tickez bei MS auf - du bezahlst dafür

Hallo zusammen, wir haben seit ca. 2 Tagen ein merkwürdiges Problem beim Einbinden eines Office 365 Postfachs. Wird versucht das Postfach in ein Outlook einzubinden, hängt sich Outlook beim Einbinden auf Das Eigenartige daran ist, dass es nur das eine Postfach betrifft, dieses dafür Rechner und Office Version unabhängig. Wird ein Outlook geöffnet, in dem das Postfach bisher eingebunden war, lädt es sich nur "zu Tode". Andere Postfächer des gleichen Tenants können Problemlos eingebunden werden. Ich kenne das Thema teilweise bei neuen Postfächern, wenn diese noch nicht sauber in Office 365 angelegt wurden, das betreffende Postfach ist allerdings über 4 Jahre alt und bisher auch sauber funktioniert. An der Office 365 Umgebung wurde auch seit längerem nichts verändert. Anmeldung im OWA funktioniert ohne Probleme. Testweise haben wir auch das Kennwort vom Postfach zurückgesetzt, leider ohne Erfolg. Jemand eine Idee? Danke und Grüße!

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