7
Keine Berechtigungen mehr im Exchange 2010
Seit einem Neustart kommt im Exchange 2010 Manager "Ihre Berechtigungen reichen zum Anzeigen dieser Daten nicht aus"
hi
ich habe eine VM mit W2K8 R2(Dns, dhcp, ad) und einem Exchange Server 2010(alles frisch installiert)
Ich bin auch als Domänen Admin am Server angemeldet und habe volle Rechte und bin auch in der Gruppe Administratoren und auch in der Gruppe Organization Management(Exchange)
Jedoch kommt bei mit seit einem Neustart im Exchange Manager immer folgende Meldung:
"Ihre Berechtigungen reichen zum Anzeigen dieser Daten nicht aus"
Obwohl ich als Admin angemeldet bin!!!
Ebenso ehe ich im Exchange Manager nur noch die Organisationseinheit, empfängerkonfig und die Toolbox, wobei ich bei keinem mehr so richtig berechtigung habe!
Woran könnte das liegen?
Vorher ging ja alles ohne Probleme.
ich weiß allerdings nicht ob der administrator noch in der richtigen exchange rolle ist.
weiß jemand den shell befehl um den administrator in die höchste exchange gruppe zu legen?
hi
ich habe eine VM mit W2K8 R2(Dns, dhcp, ad) und einem Exchange Server 2010(alles frisch installiert)
Ich bin auch als Domänen Admin am Server angemeldet und habe volle Rechte und bin auch in der Gruppe Administratoren und auch in der Gruppe Organization Management(Exchange)
Jedoch kommt bei mit seit einem Neustart im Exchange Manager immer folgende Meldung:
"Ihre Berechtigungen reichen zum Anzeigen dieser Daten nicht aus"
Obwohl ich als Admin angemeldet bin!!!
Ebenso ehe ich im Exchange Manager nur noch die Organisationseinheit, empfängerkonfig und die Toolbox, wobei ich bei keinem mehr so richtig berechtigung habe!
Woran könnte das liegen?
Vorher ging ja alles ohne Probleme.
ich weiß allerdings nicht ob der administrator noch in der richtigen exchange rolle ist.
weiß jemand den shell befehl um den administrator in die höchste exchange gruppe zu legen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 133434
Url: https://administrator.de/contentid/133434
Ausgedruckt am: 08.11.2024 um 05:11 Uhr
7 Kommentare
Neuester Kommentar
Hi,
hatte ich in einer ganz ähnlichen Konstellation auch.
Bei mir hatte es - wie ich nach ca. 3 schlaflosen Nächten rausbekommen habe - aber nicht so viel mit fehlenden Rechten zu tun, sondern war ein Problem der Verwaltungskonsole:
Versuch mal im Baum links mit der rechten Maustaste auf "Microsoft Exchange" und dann auf "Exchange Gesamtstruktur hinzufügen".
Er fragt dich dann nach dem Remote-Powershell-Server. Da gibts Du einfach den (vollqualifizierten) Namen Deines Exchangeservers an, z.B. superserver.tolledomaene.local
Dann werden explizit die Anmeldeinformationen abgefragt, hier einfach als Admin anmelden (auch wenn Du in der Sitzung sowieso schon Admin bist).
Dann hats bei mir funktioniert. warum auch immer!
Grüße
feuergott
hatte ich in einer ganz ähnlichen Konstellation auch.
Bei mir hatte es - wie ich nach ca. 3 schlaflosen Nächten rausbekommen habe - aber nicht so viel mit fehlenden Rechten zu tun, sondern war ein Problem der Verwaltungskonsole:
Versuch mal im Baum links mit der rechten Maustaste auf "Microsoft Exchange" und dann auf "Exchange Gesamtstruktur hinzufügen".
Er fragt dich dann nach dem Remote-Powershell-Server. Da gibts Du einfach den (vollqualifizierten) Namen Deines Exchangeservers an, z.B. superserver.tolledomaene.local
Dann werden explizit die Anmeldeinformationen abgefragt, hier einfach als Admin anmelden (auch wenn Du in der Sitzung sowieso schon Admin bist).
Dann hats bei mir funktioniert. warum auch immer!
Grüße
feuergott
vielen Dank, ich war auch schon fast am Verzweifeln, leider kann ich zur Ursache auch nicht viel sagen.
Nur dass ich alle Updates auf diesem Server laufen lasse.
Vielleicht war hier eines bezüglich authenifizierung dabei ?
Nur dass ich alle Updates auf diesem Server laufen lasse.
Vielleicht war hier eines bezüglich authenifizierung dabei ?
Hi,
ein Hinweis zu den Ursachen:
ich habe das Problem auf mehreren Systemen beobachten können, waren durch die Bank Testumgebungen und nie Produktivsysteme.
Hmm, wie soll man sagen, Testsysteme sind nicht immer sauber lizenziert. Aktivierung (verständlicher Weise) Fehlanzeige.
Auf diese Spur gekommen konnte ich feststellen, dass so ziemlich alle, die dieses Problem hatten, einen Vista-Kernel hatten. Zumindest hat sich das System an vielen Stellen als Vista und nicht 2008 Server gemeldet.
Man denke sich dasbei was man will, ich habe mir meinen Teil gedacht und 180 Tage Demokeys von microsoft selber empfohlen :o)
Authentifizierung ist hier aber außen vor, wo auch immer die Ursache liegen mag.
Die Meldung der Verwaltungskonsole hat einen anderen Hintergrund:
Die Vw-Konsole ist ein graphisches Interface für Powershell-Kommandos. Egal was man in der Konsole macht, es werden Powershell-Scriptlets und kommandos ausgeführt. Logt man sich ein, so wird das Kommando zum laden der Exchange-Struktur ausgeführt, die Ausgabe des Scriptlets wird ausgelesen und in süsse kleine Symbole im Baum der Konsole umgesetzt.
Um also herauszufinden warum die Konsole mist baut, lohnt es sich in die Powershell einzuloggen und Kommandos per Hand auszuführen.
Bei unserer Problematik hier habe ich gesehen, dass es garkeine Exchange-Scriptlets in der Powershell mehr gibt.
Die Konsole versucht also nun ein Scriptlet auszuführen, dass es garnicht gibt.
Das interpretiert die Konsole aber falsch. Auf nem Exchangeserver sollten die Scriptlets ja da sein (ist ne Annahme), und wenn die Powershell sagt "das gibts nicht" dann kann es nur daran liegen, dass der User nicht die Rechte hat es auszuführen.
Beispiel:
für export-mailbox muss der User eine bestimmte Rolle zugewiesen bekommen, der Admin hat diese im Standard nicht (war zumindest unter ex2007 so, 2010 glaub immernoch).
Hat man diese Rolle nicht zugewiesen, sagt die Powershell: Das Script gibt es nicht (und nicht: du darfst aber nicht).
Daher: Die Konsolole interpretiert "gibt es nicht" als "du darfst nicht".
Aber: Die Scriptlets gibts für die Powershell wirklich nicht mehr!
Warum auch immer - das ist immer noch nicht klar :o)
Grüße
Feuergott
ein Hinweis zu den Ursachen:
ich habe das Problem auf mehreren Systemen beobachten können, waren durch die Bank Testumgebungen und nie Produktivsysteme.
Hmm, wie soll man sagen, Testsysteme sind nicht immer sauber lizenziert. Aktivierung (verständlicher Weise) Fehlanzeige.
Auf diese Spur gekommen konnte ich feststellen, dass so ziemlich alle, die dieses Problem hatten, einen Vista-Kernel hatten. Zumindest hat sich das System an vielen Stellen als Vista und nicht 2008 Server gemeldet.
Man denke sich dasbei was man will, ich habe mir meinen Teil gedacht und 180 Tage Demokeys von microsoft selber empfohlen :o)
Authentifizierung ist hier aber außen vor, wo auch immer die Ursache liegen mag.
Die Meldung der Verwaltungskonsole hat einen anderen Hintergrund:
Die Vw-Konsole ist ein graphisches Interface für Powershell-Kommandos. Egal was man in der Konsole macht, es werden Powershell-Scriptlets und kommandos ausgeführt. Logt man sich ein, so wird das Kommando zum laden der Exchange-Struktur ausgeführt, die Ausgabe des Scriptlets wird ausgelesen und in süsse kleine Symbole im Baum der Konsole umgesetzt.
Um also herauszufinden warum die Konsole mist baut, lohnt es sich in die Powershell einzuloggen und Kommandos per Hand auszuführen.
Bei unserer Problematik hier habe ich gesehen, dass es garkeine Exchange-Scriptlets in der Powershell mehr gibt.
Die Konsole versucht also nun ein Scriptlet auszuführen, dass es garnicht gibt.
Das interpretiert die Konsole aber falsch. Auf nem Exchangeserver sollten die Scriptlets ja da sein (ist ne Annahme), und wenn die Powershell sagt "das gibts nicht" dann kann es nur daran liegen, dass der User nicht die Rechte hat es auszuführen.
Beispiel:
für export-mailbox muss der User eine bestimmte Rolle zugewiesen bekommen, der Admin hat diese im Standard nicht (war zumindest unter ex2007 so, 2010 glaub immernoch).
Hat man diese Rolle nicht zugewiesen, sagt die Powershell: Das Script gibt es nicht (und nicht: du darfst aber nicht).
Daher: Die Konsolole interpretiert "gibt es nicht" als "du darfst nicht".
Aber: Die Scriptlets gibts für die Powershell wirklich nicht mehr!
Warum auch immer - das ist immer noch nicht klar :o)
Grüße
Feuergott
Bei mir handelt es jedoch um ein sauber lizensiertes/installiertes System: OS: Server2008R2X64 Datacenter Edition
direkt im klassischen Sinne auf Hardwareraids aufgesetzt.
Ich habe ein Technet Abo, und alle Keys nur 1 mal aktiviert also ist dies auch auszuschließen.
Bei der Verwaltungkonsole bin ich mir nicht ganz sicher, falls hier zum Beispiel etwas im IIS falsch konfiguriert wurde macht diese ebenfalls nichts, vielleicht hat es ja mit dem ISS zu tun, Es genügt auch teilweise schon einen zweiten webserver mit ins gleiche netz zu nehmen, dann stoppt der IIS automatisch wenn er auf dem gleichen Port arbeitet.
diese meldung erscheint, wenn man sich vertippt bei der benutzeingabe
Verbindung mit Neue Exchange-Grundstruktur wird hergestellt.
Fehler beim Verbindungsversuch mit HTTPS-Protokoll "Kerberos": Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Bei Verwendung der Kerberos-Authentifizierung ist der folgende Fehler aufgetreten: Der Netzwerkpfad wurde nicht gefunden.
. Mögliche Ursachen:
- Der angegebene Benutzername oder das angegebene Kennwort ist ungültig.
- Kerberos wird verwendet, wenn keine Authentifizierungsmethode und kein Benutzername angegeben werden.
- Kerberos akzeptiert Domänenbenutzernamen, aber keine lokale Benutzernamen.
- Der Dienstprinzipalname (Service Principal Name, SPN) für den Remotecomputernamen und -port ist nicht vorhanden.
- Der Clientcomputer und der Remotecomputer befinden sich in unterschiedlichen Domänen, zwischen denen keine Vertrauensbeziehung besteht.
Wenn Sie die oben genannten Ursachen überprüft haben, probieren Sie folgende Aktionen aus:
- Suchen Sie in der Ereignisanzeige nach Ereignissen im Zusammenhang mit der Authentifizierung.
- Ändern Sie die Authentifizierungsmethode; fügen Sie den Zielcomputer der Konfigurationseinstellung "TrustedHosts" für WinRM hinzu, oder verwenden Sie den HTTPS-Transport.
Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind.
- Führen Sie den folgenden Befehl aus, um weitere Informationen zur WinRM-Konfiguration zu erhalten: winrm help config Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
Fehler beim Verbindungsversuch mit HTTPS-Protokoll "Basic": Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. In der Clientkonfiguration ist unverschlüsselter Datenverkehr derzeit deaktiviert. Ändern Sie die Clientkonfiguration, und wiederholen Sie die Anforderung. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
direkt im klassischen Sinne auf Hardwareraids aufgesetzt.
Ich habe ein Technet Abo, und alle Keys nur 1 mal aktiviert also ist dies auch auszuschließen.
Bei der Verwaltungkonsole bin ich mir nicht ganz sicher, falls hier zum Beispiel etwas im IIS falsch konfiguriert wurde macht diese ebenfalls nichts, vielleicht hat es ja mit dem ISS zu tun, Es genügt auch teilweise schon einen zweiten webserver mit ins gleiche netz zu nehmen, dann stoppt der IIS automatisch wenn er auf dem gleichen Port arbeitet.
diese meldung erscheint, wenn man sich vertippt bei der benutzeingabe
Verbindung mit Neue Exchange-Grundstruktur wird hergestellt.
Fehler beim Verbindungsversuch mit HTTPS-Protokoll "Kerberos": Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Die Anforderung kann von WinRM nicht verarbeitet werden. Bei Verwendung der Kerberos-Authentifizierung ist der folgende Fehler aufgetreten: Der Netzwerkpfad wurde nicht gefunden.
. Mögliche Ursachen:
- Der angegebene Benutzername oder das angegebene Kennwort ist ungültig.
- Kerberos wird verwendet, wenn keine Authentifizierungsmethode und kein Benutzername angegeben werden.
- Kerberos akzeptiert Domänenbenutzernamen, aber keine lokale Benutzernamen.
- Der Dienstprinzipalname (Service Principal Name, SPN) für den Remotecomputernamen und -port ist nicht vorhanden.
- Der Clientcomputer und der Remotecomputer befinden sich in unterschiedlichen Domänen, zwischen denen keine Vertrauensbeziehung besteht.
Wenn Sie die oben genannten Ursachen überprüft haben, probieren Sie folgende Aktionen aus:
- Suchen Sie in der Ereignisanzeige nach Ereignissen im Zusammenhang mit der Authentifizierung.
- Ändern Sie die Authentifizierungsmethode; fügen Sie den Zielcomputer der Konfigurationseinstellung "TrustedHosts" für WinRM hinzu, oder verwenden Sie den HTTPS-Transport.
Beachten Sie, dass Computer in der TrustedHosts-Liste möglicherweise nicht authentifiziert sind.
- Führen Sie den folgenden Befehl aus, um weitere Informationen zur WinRM-Konfiguration zu erhalten: winrm help config Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
Fehler beim Verbindungsversuch mit HTTPS-Protokoll "Basic": Beim Verbinden mit dem Remoteserver ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. In der Clientkonfiguration ist unverschlüsselter Datenverkehr derzeit deaktiviert. Ändern Sie die Clientkonfiguration, und wiederholen Sie die Anforderung. Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting".
Hallo, dieser Beitrag is zwar schon etwas älter, aber für alle die das Problem haben oder noch bekommen 
Exchange Verwaltundskonsole schließen.
Geht auf Start -> Ausführen
dann den Befehl "control keymgr.dll" eingeben
Sichert den Tresor für alles Fälle und nach dem Backup alle Einträge löschen.
Die Exchange Verwaltungskonsole wieder öffen. Jetzt wird ein Benutzername und ein Passwort abgefragt. Hier wieden den Admin rein schreiben und sich freuen das es wieder funktioniert ;)
Bei mir is alles wieder OK und ich hoff ich hab geholfen
mfg
Robert
Exchange Verwaltundskonsole schließen.
Geht auf Start -> Ausführen
dann den Befehl "control keymgr.dll" eingeben
Sichert den Tresor für alles Fälle und nach dem Backup alle Einträge löschen.
Die Exchange Verwaltungskonsole wieder öffen. Jetzt wird ein Benutzername und ein Passwort abgefragt. Hier wieden den Admin rein schreiben und sich freuen das es wieder funktioniert ;)
Bei mir is alles wieder OK und ich hoff ich hab geholfen
mfg
Robert
Vielen Dank für den Tipp. Das war bei mir ebenfalls die Fehlerursache.
Ich hatte irgendwann mal das Adminpasswort geändert. Anscheinend wurde das alte genau dort noch gespeichert. Warum auch immer.
LG
Ich hatte irgendwann mal das Adminpasswort geändert. Anscheinend wurde das alte genau dort noch gespeichert. Warum auch immer.
LG
Auch von mir vielen Dank. Auf die Sache mit dem Tresor wäre ich alleine nie gekommen, und das war's
LG
LG
