Gruppen in Microsoft 365, welche von Microsoft Teams erstellt worden sind, werden normalerweise nicht in den Adresslisten von Outlook und Co. angezeigt.
Doch das war nicht immer so.
Erst seit dem Update MC133135 werden Gruppen, die von Microsoft Teams erstellt und genutzt werden, standardmäßig in den Exchange Clients ausgeblendet. In Outlook und Outlook Web App werden sie nicht mehr angezeigt und verwirren nun auch nicht mehr.
Wie können aber nun Gruppen ausgeblendet werden, die vor dem Update erstellt worden sind?
Wie bei Microsoft üblich kann die Einstellung über das Microsoft 365 Admin-Center vorgenommen werden. Aber auch über die Powershell, lassen sich die Einstellungen vornehmen. Beide Wege zeige ich hier.
Im Microsoft 365 Admin-Center sind die Gruppen unter dem Menüpunkt „Teams und Gruppen“ und dem Unterpunkt „Aktive Teams und Gruppen“ zu finden.
Durch Auswahl der entsprechenden Gruppe kommt man in den Detailmodus bzw. Bearbeitungsmodus der ausgewählten Gruppe.
Hier kann man unter „Einstellungen“ den Punkt „Von der globalen Adressliste meiner Organisation ausblenden“ anhaken.
Die Microsoft 365 Gruppe sollte nach etwas Zeit für die Synchronisation nicht mehr angezeigt werden. (Bei uns hat dieser Weg allerdings nicht funktioniert!)
Allerdings führte Variante 2 – die Powershell-Variante bei uns zum Erfolg. Warum auch immer?!
Dazu wird zuerst eine Verbindung zu Exchange Online aufgebaut. Der Befehl
Connect-ExchangeOnline
stellt die Verbindung her.
Der Befehl zum Ausblenden der Microsoft 365 Gruppe per Powershell lautet dann:
Set-UnifiedGroup -Identity "Test" -HiddenFromExchangeClientsEnabled:$true
In unserem Beispiel ist „Test“ der Gruppen-Alias der Microsoft 365 Gruppe, die von Teams erstellt worden ist und muss entsprechend angepasst werden.
Nach ein paar Minuten Zeit für die Synchronisation wird die Gruppe nicht mehr in der Adressliste von Outlook und Co. angezeigt und kann nicht mehr für Verwirrung sorgen.
Aus Sicherheitsgründen sollte man noch die Powershell-Verbindung ordnungsgemäß mit folgendem Befehl beenden und nicht nur das Powershell-Fenster schließen:
Disconnect-ExchangeOnline
Wenn der Speicherplatz einer virtuellen Festplatte ihrer VMware zur Neige geht ist das normalerweise kein Problem.
Vorausgesetzt es steht noch nicht zugewiesener Speicher für die virtuellen Server zur Verfügung, kann die virtuelle Festplatte in vSphere mit wenigen Schritten vergrößert werden.
Dazu ruft man in vSphere die Hardware-Einstellungen der virtuellen Maschine auf.
Was normalerweise ein Routine-Eingriff ist, kann aber auch zu einem etwas größeren Problem werden. Und zwar, wenn in den Hardware-Einstellungen der virtuellen Maschine das Feld zum Vergrößern der Festplatte ausgegraut (disk size greyed out) ist und sich kein anderer Wert eintragen lässt!
Eine kurze Recherche führt zur Ursache des Problems:
Die virtuelle Maschine läuft höchstwahrscheinlich mit Snapshots. Sind Snapshots vorhanden, lassen sich die virtuellen Festplatten nicht vergrößern.
Über den Reiter Snapshots gelangen wir zu dem entsprechenden Punkt und können prüfen, ob es Snapshots gibt, die die Ursache des Problems sein könnten.
Bei uns ist dies der Fall.
Werden die Snapshots nicht mehr benötigt können diese gelöscht werden.
Dazu wählt man über das Kontext-Menü der virtuellen Maschine unter Snapshots den Punkt „Delete All Snapshots“ aus. Alternativ auch mit „Delete All“ im Reiter Snapshots.
Sind die Snapshots gelöscht, sollte die Übersicht leer sein.
Also auf ein Neues – gehen wir noch einmal in die Hardware-Einstellungen der virtuellen Maschine.
Und siehe da – es hat geklappt! Für die zu vergrößernde Festplatte lässt sich ein neuer Wert eintragen.
Das Problem ist gelöst und die Festplatte kann nun im Gast-Betriebssystem (Guest OS) vergrößert werden.
Bei der Neu-Installation unseres WSUS-Server sind wir auf die folgende Fehlermeldung gestoßen:
Fehler bei der Nachinstallationsaufgabe. Ausführliche Informationen finden Sie nachstehend.
Und nachstehend wird Folgendes angezeigt:
Die Protokolldatei befindet sich in „C:\Users\administrator\AppData\Local\Temp\WSUS_PostInstall.log“.
Die Nachinstallation (PostInstall) wird gestartet.
Schwerwiegender Fehler: Der WSUS-Dienst konnte nicht gestartet und nicht konfiguriert werden.
Aber wie kam es dazu?
Angefangen hat Alles mit zur Neige gehendem Speicherplatz bei unserem vorhandenen WSUS-Server. Aus diesem Grund wollten wir die Dateien auf ein anderes Laufwerk mit ausreichend Speicherplatz umziehen.
Eigentlich sollte dies eine Routine-Aufgabe werden – die Vorgehensweise ist in dem Artikel mmm beschrieben.
Nur leider war das beschriebene Vorgehen bei uns nicht mit Erfolg gekrönt – warum auch immer.
Das Ende vom Lied:
Wir hatten nun einen nicht mehr funktionierenden WSUS-Server, dessen Datenbank die Dateien nicht mehr gefunden hat. Nach ein wenig herumprobieren haben beschlossen, den nicht mehr funktionierenden WSUS-Server zu deinstallieren und anschließend neu zu installieren.
Das Ergebnis führte dann zu dem obigen Fehler.
Ein Blick in die erstellte Log-Datei gibt Aufschluss über das aufgetretene Problem:
Die Fehlermeldung „Die Konfiguration kann nicht gespeichert werden, da der Server noch eine frühere
Konfigurationsänderung verarbeitet.“ lässt darauf schließen, dass bei der Deinstallation nicht Alles deinstalliert worden ist.
Eine Prüfung bestätigt dies – sowohl Dateien als auch die Datenbank sind nicht gelöscht worden.
Nun zur Fehlerbehebung:
Das Problem scheint also neben den nicht gelöschten Dateien auch die Windows-Interne Datenbank zu sein, die SUSDB, welche höchstwahrscheinlich noch existiert.
Sofern nicht vorhanden, muss als Erstes das SQL Management Studio heruntergeladen werden – den Download findet man hier: Download SQL Management Studio
Im Anschluss müssen die Einstellungen des WSUS aus der Registry (über Regedit öffnen) gelesen werden. Diese finden sich in folgendem Pfad:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
Es werden die Werte SqlServerName, SqlDatabaseName und ContentDir benötigt.
Nun haben wir alle benötigten Informationen zusammen und können mit der Bereinigung starten.
Wir stoppen die WSUS-Dienste auf dem Server – beispielsweise über die CMD-Eingabeaufforderung, die als Administrator geöffnet wird.
In der Konsole führen wir die folgenden drei Befehle aus:
net stop W3SVC
net stop WSusCertServer
net stop WsusService
In folgendem Screenshot benötigte der WsusService etwas länger zum beenden, daher die Fehlermeldung:
Sind die Dienste gestoppt, öffnen wir das (installierte) SQL Management Studio und bauen eine Verbindung zur Windows Internal Database mit folgendem Servernamen auf:
\\.\pipe\MICROSOFT##WID\tsql\query
Die Datenbank SUSDB lässt sich über das Kontextmenü löschen.
Alternativ lässt sich die Datenbank auch mit folgendem SQL-Befehl löschen:
ALTER DATABASE SUSDB
SET OFFLINE WITH ROLLBACK IMMEDIATE;
DROP DATABASE SUSDB;
Ist die Datenbank gelöscht müssen noch die dazugehörigen Dateien auf der Festplatte gelöscht werden. Diese finden sich im Verzeichnis
C:\Windows\WID\Data
und heißen
SUSDB.mdf und SUSDB_log.ldf
Falls noch nicht geschehen muss noch der Content gelöscht werden. Das Verzeichnis (ContentDir) haben wir aus der Registry ausgelesen – in unserem Fall H:\WSUS.
Ist all das erledigt, kann die Nachinstallationsaufgabe erneut – mit nachfolgendem Kommando (aus der Eingabeaufforderung als Administrator) – gestartet werden und sollte ohne Fehler durchlaufen:
"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall CONTENT_DIR="H:\WSUS"
Nachdem die Bereinigung durchgeführt worden ist, haben wir wieder einen frischen WSUS.