20
Powershell Exchange SnapIn MoveRequest funkt immer zu localhost
Hallo zusammen,
ich bewege mich in folgender Umgebung:
- kürzlich von E2010 auf E2016CU14 gewechselt
- ExchangeVerwaltungstools sind auf einem separaten 2012er R2 installiert (ein Programm benötigt diese)
- PowerShell Version 5.1
Was habe ich vor?
Ich möchte ein Benutzerpostfach in eine andere Datenbank verschieben.
Wie ist mein Vorgehen?
1. Ich öffne PowerShell im Administratormodus.
2. Befehl:
3. Wird angenommen!
4. Befehl:
5. Folgende Fehlermeldung erscheint dann:
Ich musste relevante Sachen verpixeln. Kurz und knapp: Er sucht den Exchange Replication Service auf meinem 2012er R2 auf dem natürlich kein Exchange installiert ist. Nur die Verwaltungstools. Ich habe auch schon die Verwaltungstools neu installiert, es ist aber keine Besserung eingetreten.
Setze ich z.B. ein ab, das funktioniert anstandslos.
Ich habe mir heute schon den ganzen Tag den Kopf zerbrochen, Google bemüht, aber so wirklich komme ich nicht auf die Lösung.
In der "richtigen" Exchange Management Shell funktioniert es natürlich tadellos. Aber das bringt mir nichts, weil der Move Befehl in diversen Skripts verarbeitet wird, die bei uns regelmäßig laufen müssen. Ich hoff einer von euch hat die Eingebung die mir so sehr fehlt...
Mit vielen Grüßen verbleibe ich und danke schon mal für ein paar Ansätze
PS: Unter dem 2010er hat das alles genau so einwandfrei funktioniert. Nur dass der Befehl zum SnapIn natürlich anders heißt (Statt "SnapIn" am Ende ein "E2010")
ich bewege mich in folgender Umgebung:
- kürzlich von E2010 auf E2016CU14 gewechselt
- ExchangeVerwaltungstools sind auf einem separaten 2012er R2 installiert (ein Programm benötigt diese)
- PowerShell Version 5.1
Was habe ich vor?
Ich möchte ein Benutzerpostfach in eine andere Datenbank verschieben.
Wie ist mein Vorgehen?
1. Ich öffne PowerShell im Administratormodus.
2. Befehl:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn4. Befehl:
New-MoveRequest -Identity Mustermann -TargetDatabase MBX22Ich musste relevante Sachen verpixeln. Kurz und knapp: Er sucht den Exchange Replication Service auf meinem 2012er R2 auf dem natürlich kein Exchange installiert ist. Nur die Verwaltungstools. Ich habe auch schon die Verwaltungstools neu installiert, es ist aber keine Besserung eingetreten.
Setze ich z.B. ein
Enable-Mailbox -Identiy MustermannIch habe mir heute schon den ganzen Tag den Kopf zerbrochen, Google bemüht, aber so wirklich komme ich nicht auf die Lösung.
In der "richtigen" Exchange Management Shell funktioniert es natürlich tadellos. Aber das bringt mir nichts, weil der Move Befehl in diversen Skripts verarbeitet wird, die bei uns regelmäßig laufen müssen. Ich hoff einer von euch hat die Eingebung die mir so sehr fehlt...
Mit vielen Grüßen verbleibe ich und danke schon mal für ein paar Ansätze
PS: Unter dem 2010er hat das alles genau so einwandfrei funktioniert. Nur dass der Befehl zum SnapIn natürlich anders heißt (Statt "SnapIn" am Ende ein "E2010")
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: 505360
Url: https://administrator.de/forum/powershell-exchange-snapin-moverequest-funkt-immer-zu-localhost-505360.html
Ausgedruckt am: 23.12.2024 um 11:12 Uhr
20 Kommentare
Neuester Kommentar
Moin,
wie wäre es mit -RemoteHostName <Fqdn> als Parameter?
LG
Robin
wie wäre es mit -RemoteHostName <Fqdn> als Parameter?
LG
Robin
Starte doch ein Remote Command auf dem Server, wo sich die Mailbox befindet.
Hier
Edit: RobDie war schneller
Hier
Edit: RobDie war schneller
Mein Posting war auf den PS-Befehl "New-MoveRequest" bezogen: https://docs.microsoft.com/en-us/powershell/module/exchange/move-and-mig ...
Hallo
Enter-PSSession zum Exchange. Der Rest ist dann wie gehabt.
Gruß Mikro
Enter-PSSession zum Exchange. Der Rest ist dann wie gehabt.
Gruß Mikro
Du kannst New-Moverequest auch Remote auf dem richtigen Zielrechner ausführen lassen.
Habe ich mal eben probiert (also das Remote Hostname) Dann kommt als Rückmeldung dass der User bereits ein primäres Postfach besitzt?! Hö?
Hallo Mikrofonpartner... Genau das will ich ja nicht über PSSession. Der Befehl wird dynamisch in Automatisierungsskripten aufgerufen. Wie gesagt mit 2010 lief das so wie ich es bisher gemacht habe. Muss doch auch weiterhin so gehen. Will nicht mein gesamtes Skript umbauen, dass immerhin 1500 Zeilen umfasst...
Zitat von @Trekki1990:
Hallo Mikrofonpartner... Genau das will ich ja nicht über PSSession. Der Befehl wird dynamisch in Automatisierungsskripten aufgerufen. Wie gesagt mit 2010 lief das so wie ich es bisher gemacht habe. Muss doch auch weiterhin so gehen. Will nicht mein gesamtes Skript umbauen, dass immerhin 1500 Zeilen umfasst...
Hallo Mikrofonpartner... Genau das will ich ja nicht über PSSession. Der Befehl wird dynamisch in Automatisierungsskripten aufgerufen. Wie gesagt mit 2010 lief das so wie ich es bisher gemacht habe. Muss doch auch weiterhin so gehen. Will nicht mein gesamtes Skript umbauen, dass immerhin 1500 Zeilen umfasst...
Probier doch erstmal, ob du mit Enter-PSSession überhaupt an den Exchange kommst. Ist ja mit einem einfachen Get-Mailbox oder set-mailboxautoreplyconfiguration schnell getestet.
Get-Mailbox -Identity MustermannSet-MailboxAutoReplyConfiguration -Identity Mustermannspuckt wieder folgenden Fehler aus:
Set-MailboxAutoReplyConfiguration : Failed to load assembly;
Type=Microsoft.Exchange.Assistants.ItemAssistantContextFactory, Assembly=Microsoft.Exchange.Assistants,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
In Zeile:1 Zeichen:1Hier stimmt doch irgendwas mit den Verwaltungstools nicht habe ich das Gefühl... Vorher waren die 2010er drauf. Die habe ich deinstalliert.
Versuch mit Enter-PSSession hat folgendes zu Tage gefördert.
Anmeldung mit USER1 (ist der Account der die Scripte bisher automatisch ausgeführt hat):
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER1
[FQDNSERVERNAME]: PS C:\Users\USER1\Documents> Add-PSSnapin Microsoft.Exchange.Management.Powershell.SnapIn
[FQDNSERVERNAME]: PS C:\Users\USER1\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER1' sind ungültig.
+ CategoryInfo : NotSpecified: (:) , ADInvalidCredentialException
+ FullyQualifiedErrorId : [Server=SERVERNAME=e191c275-b848-41f6-b20e-7a2ac04de93a,TimeStamp=17.10.2019 05:
27:05] [FailureCategory=Cmdlet-ADInvalidCredentialException] 248E7879Anmeldung mit USER2 (Domänenadmin Account):
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER2
[FQDNSERVERNAME]: PS C:\Users\USER2\Documents> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
[FQDNSERVERNAME]: PS C:\Users\USER2\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER2' sind ungültig.
+ CategoryInfo : NotSpecified: (:) , ADInvalidCredentialException
+ FullyQualifiedErrorId : [Server=SERVERNAME,RequestId=2f08982c-dabc-4c63-916c-f1fa02c65db1,TimeStamp=17.10.2019 05:
35:44] [FailureCategory=Cmdlet-ADInvalidCredentialException] BBE3AD99Wieso sollen denn jetzt meine Anmeldedaten der User ungültig sein?
Guten Morgen
Was sagen die Logs auf Seiten Exchange, als du den MoveRequest ausgeführt hast?
Gruß Mikro
Die User1 und 2 werden auf dem Exchange Server nicht existieren. Nur Administratoren mit Exchange Rechten dürfen da herum werkeln.
Zitat von @NordicMike:
Die User1 und 2 werden auf dem Exchange Server nicht existieren. Nur Administratoren mit Exchange Rechten dürfen da herum werkeln.
Die User1 und 2 werden auf dem Exchange Server nicht existieren. Nur Administratoren mit Exchange Rechten dürfen da herum werkeln.
Du kannst dem Nutzer doch über RoleAssignment-Policies Berechtigungen geben. Würde er fehlende Rechte haben, wäre die Rückmeldung eine andere.
Genau das will ich ja nicht über PSSession.
Eine interaktive Enter-PSSession ist bei Sessions ja nicht zwingend nötig, über Import-PSSession geht es auch automatisiert non interactive...Nutze Exchange-Verbindungen so seit Jahren immer ohne extra Tools, no Problem ...
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://meinexserver.fqdn/powershell/?SerializationLevel=Full" -Authentication Kerberos
Import-PSSession $session -DisableNameChecking -AllowClobber | out-nullZitat von @Mikrofonpartner:
Du kannst dem Nutzer doch über RoleAssignment-Policies Berechtigungen geben. Würde er fehlende Rechte haben, wäre die Rückmeldung eine andere.
Das könnte er einfach testen. Er kann ja mal testweise den Domänenadmin eingeben, wenn das funktioniert, kann er auf die gewünschten User umschwenken und dementsprechend Delegierungen verteilen.Du kannst dem Nutzer doch über RoleAssignment-Policies Berechtigungen geben. Würde er fehlende Rechte haben, wäre die Rückmeldung eine andere.
Zitat von @NordicMike:
Zitat von @Mikrofonpartner:
Du kannst dem Nutzer doch über RoleAssignment-Policies Berechtigungen geben. Würde er fehlende Rechte haben, wäre die Rückmeldung eine andere.
Das könnte er einfach testen. Er kann ja mal testweise den Domänenadmin eingeben, wenn das funktioniert, kann er auf die gewünschten User umschwenken und dementsprechend Delegierungen verteilen.Du kannst dem Nutzer doch über RoleAssignment-Policies Berechtigungen geben. Würde er fehlende Rechte haben, wäre die Rückmeldung eine andere.
Siehe
Zitat von @Trekki1990:
Anmeldung mit USER2 (Domänenadmin Account):
Anmeldung mit USER2 (Domänenadmin Account):
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER2
> [FQDNSERVERNAME]: PS C:\Users\USER2\Documents> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
> [FQDNSERVERNAME]: PS C:\Users\USER2\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
> Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER2' sind ungültig.
> + CategoryInfo : NotSpecified: (:) , ADInvalidCredentialException
> + FullyQualifiedErrorId : [Server=SERVERNAME,RequestId=2f08982c-dabc-4c63-916c-f1fa02c65db1,TimeStamp=17.10.2019 05:
> 35:44] [FailureCategory=Cmdlet-ADInvalidCredentialException] BBE3AD99Laut seiner Aussage ist USER2 ja ein Domainadmin.
Das habe ich nicht gefunden. Ich habe zwei mal durch gescrollt und es nicht gesehen. Erst die Suchfunktion hat es dann gefunden Du hast recht ...
Du hast recht ...Zitat von @141320:
Eine interaktive Enter-PSSession ist bei Sessions ja nicht zwingend nötig, über Import-PSSession geht es auch automatisiert non interactive...
Nutze Exchange-Verbindungen so seit Jahren immer ohne extra Tools, no Problem ...
Feddisch.
Eine interaktive Enter-PSSession ist bei Sessions ja nicht zwingend nötig, über Import-PSSession geht es auch automatisiert non interactive...
Nutze Exchange-Verbindungen so seit Jahren immer ohne extra Tools, no Problem ...
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://meinexserver.fqdn/powershell/?SerializationLevel=Full" -Authentication Kerberos
Import-PSSession $session -DisableNameChecking -AllowClobber | out-nullDas habe ich probiert. Das funktioniert soweit. Wäre ein Workaround. Danke dafür!
Was mir leider immer noch nicht in den Kopf geht warum er bei einem neuen MoveRequest immer den localhost ansprechen will und nicht den zuständigen Exchange Server. Alle anderen Befehle wie Get-Mailbox, Remove-MoveRequest, Enable-Mailbox etc. laufen wunderbar. Nur der New-MoveRequest fragt immer seinen eigenen Client ab.
Habe die Verwaltungstools nun auch mal auf zwei weiteren anderen Clients installiert. Kommt folgende (andere Meldung):
New-MoveRequest : Der Typeninitialisierer für "Microsoft.Exchange.MailboxReplicationService.RequestJobLog" hat eine
Ausnahme verursacht.
In Zeile:1 Zeichen:1
+ New-MoveRequest -Identity mustermann -TargetDatabase MBX22
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [New-MoveRequest], TypeInitializationException
+ FullyQualifiedErrorId : System.TypeInitializationException,Microsoft.Exchange.Management.Migration.MailboxReplic
ation.MoveRequest.NewMoveRequestIch werd nicht schlau draus.
Prüfe folgendes:
In ADUC die Eigenschaften des Exchange Computerkontos aufrufen und im Attribut-Editor das Attribut AdminCount prüfen. Dies sollte auf 0 stehen! Ist dies nicht der Fall dann wurde der EX irgendwann einmal zu einer der geschützen Gruppen hinzugefügt, dies sind folgende
Ist das sichergestellt das Attribut AdminCount dann auf 0 setzen und den Exchange neu starten.
Zusätzlich kann mit Test-MigrationServerAvailability die allgemeine Verfügbarkeit des Servers abgerufen werden, erst wenn das CMDLet keine Fehler mehr wirft ist sichergestellt das New-Moverequest sicher arbeiten kann.
In ADUC die Eigenschaften des Exchange Computerkontos aufrufen und im Attribut-Editor das Attribut AdminCount prüfen. Dies sollte auf 0 stehen! Ist dies nicht der Fall dann wurde der EX irgendwann einmal zu einer der geschützen Gruppen hinzugefügt, dies sind folgende
- Administratoren
- Konten-Operatoren
- Server-Operatoren
- Druck-Operatoren
- Sicherungsoperatoren
- Domänen-Admins
- Schema-Admins
- Organisations-Admins
- Zertifikat-Herausgeber
- Computer
- Installation von Exchange
- Domänenserver
- Exchange-Server
- Exchange Trusted Subsystem
- Verfügbarkeit von verwalteten Servern
Ist das sichergestellt das Attribut AdminCount dann auf 0 setzen und den Exchange neu starten.
Zusätzlich kann mit Test-MigrationServerAvailability die allgemeine Verfügbarkeit des Servers abgerufen werden, erst wenn das CMDLet keine Fehler mehr wirft ist sichergestellt das New-Moverequest sicher arbeiten kann.
Zitat von @141575:
Prüfe folgendes:
In ADUC die Eigenschaften des Exchange Computerkontos aufrufen und im Attribut-Editor das Attribut AdminCount prüfen. Dies sollte auf 0 stehen!
Prüfe folgendes:
In ADUC die Eigenschaften des Exchange Computerkontos aufrufen und im Attribut-Editor das Attribut AdminCount prüfen. Dies sollte auf 0 stehen!
Weder das Exchange COMPUTERkonto noch das COMPUTERkonto irgendeines anderen Clients den ich geprüft habe stehen die Attribute auf 0 oder 1. Da steht "Nicht festgelegt". Bei dem BENUTZERkonto dass den Move-Request durchführen soll steht jedoch eine 1 drin und ist ein Domänenadmin.
Bzgl. Test-MigrationServerAvailbility muss ich noch testen.
Bei dem BENUTZERkonto dass den Move-Request durchführen soll steht jedoch eine 1 drin und ist ein Domänenadmin.
Ist ja auch vollkommen normal und auch gut so! Du solltest dich mal mit dem Attribut beschäftigen, und was es eigentlich aussagt.Es ging hier nur darum falls das Computerkonto das Flag besitzt gibt es ähnliche Probleme mit der Authentifizierung am EX.
