trekki1990
Goto Top

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

pwrshllerror

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
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 face-smile

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")

Content-Key: 505360

Url: https://administrator.de/contentid/505360

Ausgedruckt am: 28.03.2024 um 16:03 Uhr

Mitglied: 140962
140962 16.10.2019 um 20:58:47 Uhr
Goto Top
Moin,

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

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

Hier

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

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

Gruß Mikro
Mitglied: NordicMike
NordicMike 16.10.2019 um 21:09:10 Uhr
Goto Top
Du kannst New-Moverequest auch Remote auf dem richtigen Zielrechner ausführen lassen.
Mitglied: Trekki1990
Trekki1990 16.10.2019 aktualisiert um 21:16:58 Uhr
Goto Top
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
Trekki1990 16.10.2019 um 21:19:27 Uhr
Goto Top
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
Mikrofonpartner 16.10.2019 um 22:54:55 Uhr
Goto Top
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
Trekki1990 17.10.2019 aktualisiert um 08:01:23 Uhr
Goto Top
Get-Mailbox -Identity Mustermann
funktioniert. Da gibt er mir das Postfach aus.

Set-MailboxAutoReplyConfiguration -Identity Mustermann

spuckt 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: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):

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] 248E7879

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] BBE3AD99


Wieso sollen denn jetzt meine Anmeldedaten der User ungültig sein?
Mitglied: Mikrofonpartner
Mikrofonpartner 17.10.2019 um 08:17:08 Uhr
Goto Top
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
NordicMike 17.10.2019 um 12:38:29 Uhr
Goto Top
Die User1 und 2 werden auf dem Exchange Server nicht existieren. Nur Administratoren mit Exchange Rechten dürfen da herum werkeln.
Mitglied: Mikrofonpartner
Mikrofonpartner 17.10.2019 um 12:43:02 Uhr
Goto Top
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
141320 17.10.2019 aktualisiert um 12:51:23 Uhr
Goto Top
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-null
Feddisch.
Mitglied: NordicMike
NordicMike 17.10.2019 um 12:51:32 Uhr
Goto Top
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
Mikrofonpartner 17.10.2019 um 13:23:43 Uhr
Goto Top
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):

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] BBE3AD99


Laut seiner Aussage ist USER2 ja ein Domainadmin.
Mitglied: NordicMike
NordicMike 17.10.2019 um 13:27:58 Uhr
Goto Top
Das habe ich nicht gefunden. Ich habe zwei mal durch gescrollt und es nicht gesehen. Erst die Suchfunktion hat es dann gefunden face-smile Du hast recht ...
Mitglied: Trekki1990
Trekki1990 22.10.2019 um 14:14:00 Uhr
Goto Top
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 ...
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://meinexserver.fqdn/powershell/?SerializationLevel=Full" -Authentication Kerberos  
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):
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.NewMoveRequest

Ich werd nicht schlau draus.
Mitglied: 141575
141575 22.10.2019 aktualisiert um 14:53:06 Uhr
Goto Top
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
Trekki1990 22.10.2019 um 15:20:08 Uhr
Goto Top
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
141575 22.10.2019 aktualisiert um 17:33:20 Uhr
Goto Top
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.