Powershell Exchange SnapIn MoveRequest funkt immer zu localhost

Mitglied: Trekki1990

Trekki1990 (Level 1)

16.10.2019, aktualisiert 20:56 Uhr, 388 Aufrufe, 20 Kommentare

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:
01.
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
3. Wird angenommen!
4. Befehl:
01.
New-MoveRequest -Identity Mustermann -TargetDatabase MBX22
5. Folgende Fehlermeldung erscheint dann:

pwrshllerror - Klicke auf das Bild, um es zu vergrößern

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
01.
Enable-Mailbox -Identiy Mustermann
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")
Mitglied: RobDie
16.10.2019 um 20:58 Uhr
Moin,

wie wäre es mit -RemoteHostName <Fqdn> als Parameter?

LG
Robin
Mitglied: NordicMike
16.10.2019, aktualisiert um 21:01 Uhr
Starte doch ein Remote Command auf dem Server, wo sich die Mailbox befindet.

Hier

Edit: RobDie war schneller
Mitglied: RobDie
16.10.2019 um 21:03 Uhr
Mein Posting war auf den PS-Befehl "New-MoveRequest" bezogen: https://docs.microsoft.com/en-us/powershell/module/exchange/move-and-mig ...
Mitglied: Mikrofonpartner
16.10.2019 um 21:09 Uhr
Hallo

Enter-PSSession zum Exchange. Der Rest ist dann wie gehabt.

Gruß Mikro
Mitglied: NordicMike
16.10.2019 um 21:09 Uhr
Du kannst New-Moverequest auch Remote auf dem richtigen Zielrechner ausführen lassen.
Mitglied: Trekki1990
16.10.2019, aktualisiert um 21:16 Uhr
Habe ich mal eben probiert (also das Remote Hostname) Dann kommt als Rückmeldung dass der User bereits ein primäres Postfach besitzt?! Hö?
Mitglied: Trekki1990
16.10.2019 um 21:19 Uhr
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...
Mitglied: Mikrofonpartner
16.10.2019 um 22:54 Uhr
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...

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.
Mitglied: Trekki1990
17.10.2019, aktualisiert um 08:01 Uhr
01.
Get-Mailbox -Identity Mustermann
funktioniert. Da gibt er mir das Postfach aus.

01.
Set-MailboxAutoReplyConfiguration -Identity Mustermann
spuckt wieder folgenden Fehler aus:

01.
Set-MailboxAutoReplyConfiguration : Failed to load assembly;
02.
Type=Microsoft.Exchange.Assistants.ItemAssistantContextFactory, Assembly=Microsoft.Exchange.Assistants,
03.
Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
04.
In Zeile:1 Zeichen:1
Hier 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):

01.
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER1
02.
[FQDNSERVERNAME]: PS C:\Users\USER1\Documents> Add-PSSnapin Microsoft.Exchange.Management.Powershell.SnapIn
03.
[FQDNSERVERNAME]: PS C:\Users\USER1\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
04.
Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER1' sind ungültig.
05.
    + CategoryInfo          : NotSpecified: (:) [], ADInvalidCredentialException
06.
    + FullyQualifiedErrorId : [Server=SERVERNAME=e191c275-b848-41f6-b20e-7a2ac04de93a,TimeStamp=17.10.2019 05:
07.
   27:05] [FailureCategory=Cmdlet-ADInvalidCredentialException] 248E7879
Anmeldung mit USER2 (Domänenadmin Account):

01.
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER2
02.
[FQDNSERVERNAME]: PS C:\Users\USER2\Documents> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
03.
[FQDNSERVERNAME]: PS C:\Users\USER2\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
04.
Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER2' sind ungültig.
05.
    + CategoryInfo          : NotSpecified: (:) [], ADInvalidCredentialException
06.
    + FullyQualifiedErrorId : [Server=SERVERNAME,RequestId=2f08982c-dabc-4c63-916c-f1fa02c65db1,TimeStamp=17.10.2019 05:
07.
   35:44] [FailureCategory=Cmdlet-ADInvalidCredentialException] BBE3AD99

Wieso sollen denn jetzt meine Anmeldedaten der User ungültig sein?
Mitglied: Mikrofonpartner
17.10.2019 um 08:17 Uhr
Zitat von Trekki1990:

Wieso 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
Mitglied: NordicMike
17.10.2019 um 12:38 Uhr
Die User1 und 2 werden auf dem Exchange Server nicht existieren. Nur Administratoren mit Exchange Rechten dürfen da herum werkeln.
Mitglied: Mikrofonpartner
17.10.2019 um 12:43 Uhr
Zitat von NordicMike:

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.
Mitglied: 141320
17.10.2019, aktualisiert um 12:51 Uhr
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 ...
01.
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://meinexserver.fqdn/powershell/?SerializationLevel=Full" -Authentication Kerberos
02.
Import-PSSession $session -DisableNameChecking -AllowClobber | out-null
Feddisch.
Mitglied: NordicMike
17.10.2019 um 12:51 Uhr
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.
Mitglied: Mikrofonpartner
17.10.2019 um 13:23 Uhr
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.

Siehe


Zitat von Trekki1990:

Anmeldung mit USER2 (Domänenadmin Account):

01.
PS C:\Windows\system32> Enter-PSSession -ComputerName FQDNSERVERNAME -Credential USER2
02.
> [FQDNSERVERNAME]: PS C:\Users\USER2\Documents> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
03.
> [FQDNSERVERNAME]: PS C:\Users\USER2\Documents> New-MoveRequest -Identity mustermann -TargetDatabase MBX22
04.
> Fehler bei Active Directory-Vorgang auf . Die angegebenen Anmeldeinformationen für 'DOMAIN\USER2' sind ungültig.
05.
>     + CategoryInfo          : NotSpecified: (:) [], ADInvalidCredentialException
06.
>     + FullyQualifiedErrorId : [Server=SERVERNAME,RequestId=2f08982c-dabc-4c63-916c-f1fa02c65db1,TimeStamp=17.10.2019 05:
07.
>    35:44] [FailureCategory=Cmdlet-ADInvalidCredentialException] BBE3AD99

Laut seiner Aussage ist USER2 ja ein Domainadmin.
Mitglied: NordicMike
17.10.2019 um 13:27 Uhr
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 ...
Mitglied: Trekki1990
22.10.2019 um 14:14 Uhr
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 ...
01.
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://meinexserver.fqdn/powershell/?SerializationLevel=Full" -Authentication Kerberos
02.
Import-PSSession $session -DisableNameChecking -AllowClobber | out-null
Feddisch.

Das 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):
01.
New-MoveRequest : Der Typeninitialisierer für "Microsoft.Exchange.MailboxReplicationService.RequestJobLog" hat eine
02.
Ausnahme verursacht.
03.
In Zeile:1 Zeichen:1
04.
+ New-MoveRequest -Identity mustermann -TargetDatabase MBX22
05.
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
06.
    + CategoryInfo          : NotSpecified: (:) [New-MoveRequest], TypeInitializationException
07.
    + FullyQualifiedErrorId : System.TypeInitializationException,Microsoft.Exchange.Management.Migration.MailboxReplic
08.
   ation.MoveRequest.NewMoveRequest
Ich werd nicht schlau draus.
Mitglied: 141575
22.10.2019, aktualisiert um 14:53 Uhr
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
  • Administratoren
  • Konten-Operatoren
  • Server-Operatoren
  • Druck-Operatoren
  • Sicherungsoperatoren
  • Domänen-Admins
  • Schema-Admins
  • Organisations-Admins
  • Zertifikat-Herausgeber
Das Computerkonto darf nur folgenden Gruppen angehören
  • 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.
Mitglied: Trekki1990
22.10.2019 um 15:20 Uhr
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!

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.
Mitglied: 141575
22.10.2019, aktualisiert um 17:33 Uhr
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.
Titel: Powershell Exchange SnapIn MoveRequest funkt immer zu localhost
Content-ID: 505360
Art des Inhalts: Frage
Ausgedruckt am: 08.12.2019 um 07:09:39 Uhr
URL: https://administrator.de/contentid/505360