Zum Inhalt wechseln


Foto

wurde migriert?


  • Bitte melde dich an um zu Antworten
51 Antworten in diesem Thema

#16 NorbertFe

NorbertFe

    Expert Member

  • 30.600 Beiträge

 

Geschrieben 25. Januar 2012 - 08:56

Kann ich nicht, die Doku über die Migration ist unvollständig - War mein Vorgänger.
Scheinbar aber nicht, da das Objekt "Folder Hierachies" in der anderen Gruppe nicht vorhanden ist.


Dann würd ich nur die Serverobjekte löschen. Wobei mir unklar ist, wie man eine Migration durchführen kann, und sie dann nicht korrekt beendet. Schau auch mal nach, ob die Domain und Enterprise RUS Einträge gelöscht wurden.

Bye
Norbert

Make something i***-proof and they will build a better i***.


#17 DarkmindNew

DarkmindNew

    Newbie

  • 19 Beiträge

 

Geschrieben 25. Januar 2012 - 09:04

Hi

im Normalfall ist es so, dass man auf einem Benutzer Account der migriert wurde, via ADSIedit unter dem Attribut LegacyExchangeDN die alte administrative Gruppe findet. Dies wird beim Postfachverschieben nicht geändert.

Diese zu ändern ist auch nicht ratsam, da dies meist ein neues Outlook Profil zu folge hat. bei mehreren hundert Postfächern durchaus nicht praktiabel. :eek:

Übrigens IMHO ein weiterer Grund warum man die alte Administrative Gruppe via ADSI nicht einfach löschen sollte, auch wen nsich darin keine Server mehr befinden was bei einer sauberen migration üblich ist.

/edit:

hier noch weiteres dazu:

http://www.msxfaq.de...yexchangedn.htm



Grüsse

Darki

#18 NorbertFe

NorbertFe

    Expert Member

  • 30.600 Beiträge

 

Geschrieben 25. Januar 2012 - 09:37

Hi

im Normalfall ist es so, dass man auf einem Benutzer Account der migriert wurde, via ADSIedit unter dem Attribut LegacyExchangeDN die alte administrative Gruppe findet. Dies wird beim Postfachverschieben nicht geändert.

Diese zu ändern ist auch nicht ratsam, da dies meist ein neues Outlook Profil zu folge hat. bei mehreren hundert Postfächern durchaus nicht praktiabel. :eek:

Übrigens IMHO ein weiterer Grund warum man die alte Administrative Gruppe via ADSI nicht einfach löschen sollte, auch wen nsich darin keine Server mehr befinden was bei einer sauberen migration üblich ist.

/edit:

hier noch weiteres dazu:

MSXFAQ.DE - LegacyExchangeDN



Ja, wenn man weiß was man tut. Schrub ich hier im Thread glaub ich mehrfach.

Bye
Norbert

Make something i***-proof and they will build a better i***.


#19 DarkmindNew

DarkmindNew

    Newbie

  • 19 Beiträge

 

Geschrieben 25. Januar 2012 - 09:45

Ja, wenn man weiß was man tut. Schrub ich hier im Thread glaub ich mehrfach.

Bye
Norbert


Also gut,

um Powershelladmins Anfangsfrage zu beantworten..

siehe bei einem älteren Exchange Postfächern nach ob noch im Attribut LegacyExchangeDN eine alte administrative Gruppe zu finden ist.
Hier sieht man ob migriert wurde oder nicht.

Alles andere hat Norbert schon beantwortet.

ich hoffe du bist mit dieser Antwort ebenfalls zufrieden Norbert. :rolleyes:

#20 NorbertFe

NorbertFe

    Expert Member

  • 30.600 Beiträge

 

Geschrieben 25. Januar 2012 - 09:47

ch hoffe du bist mit dieser Antwort ebenfalls zufrieden Norbert. :rolleyes:


Ist das wirklich wichtig? :shock:

Bye
Norbert

Make something i***-proof and they will build a better i***.


#21 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 09:53

Ist das wirklich wichtig? :shock:

Bye
Norbert


Norbert betreibt Qualitätssicherung :-)

Schaue mir das alles im Verlauf des Tages an. Gerade Forefront for Exchange installiert und konfiguriert -> funktioniert wunderbar.
OT:
Haben hier die Filterregeln einen Bug? - Habe in Regel 1 ) Dateitypen blockiert und in Regel 2) Ausnahme für Absender erstellt (hier die internen Domänen eingetragen). Die Option "Datei" ist in Regel 2 aktiviert.
Schlüsselwörter und co Filter werden durch Regel 2 auch korrekt außer Kraft gesetzt.
edit: kein Bug (Die Positiv Regel läuft nur auf den Hubserver, entsprechend muss man nur die Postfachscans etc bei Regel 1 deaktivieren klappt wunderbar :)
Macht einen sehr soliden Eindruck - tolles Produkt, lässt sich soweit an die Ansprüche anpassen, wie es sein soll.

Bearbeitet von PowerShellAdmin, 25. Januar 2012 - 10:45.


#22 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 13:50

habe eine Sysstate Sicherung unseres primären DCs ausgeführt.
Anschließend die Objekte gelöscht.

Nun meckert der Exchangeserver fleißig, Konten die in der alten Routinggruppe waren zeigen Fehlermeldungen.

Wie gehe ich jetzt am besten vor, a)wiederherstellen des Sysstates oder B) korrigieren.

#23 RobertWi

RobertWi

    Expert Member

  • 4.987 Beiträge

 

Geschrieben 25. Januar 2012 - 14:04

Welche Objekte hast Du denn gelöscht?

Tipp: Zwei Stunden Try&Error können 10 Minuten lesen im Technet sparen!


#24 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 14:05

Ich habe unterhalb von Server "Server1" sowie "Server2" entfernt. Mehr nicht.
Beide Serverkonten im AD sind deaktiviert und die Systeme sind seit >1,5 Jahren offline.

Trotzdem meckert der Exchange dass es nun zu Problemen mit den Routinggruppen gibt -davon sind eine handvoll älterer Konten betroffen und man das AD Objekt ... wiederherstellen soll.

Reicht es aus manuell per oder per Powershell das Legacy Attribut umzusetzen - welche Auswirkungen hätte das ?

#25 RobertWi

RobertWi

    Expert Member

  • 4.987 Beiträge

 

Geschrieben 25. Januar 2012 - 14:09

Denn entferne noch das "CN=SERVERS" aber nicht die Administrative Gruppe selbst.

Ansonsten wären aussagekräftige Fehlermeldungen hilfreich.

Tipp: Zwei Stunden Try&Error können 10 Minuten lesen im Technet sparen!


#26 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 14:12

folgende Ergeignisse treffen mehrfach ein: (MSEXchange ADAccess)
Wobei die ID 5016 behoben sein sollte - habe die alten Migrationsconnectoren entfernt.

Ereignis ID 5015:
Microsoft Exchange kann die Route zum Quell-Transport-Server oder Basis-MTA-Server "CN=Microsoft MTA\0ADEL:f9e74536-34e4-41ee-944a-7cedf8ea2917,CN=Deleted Objects,CN=Configuration,DC=ffm,DC=xxx,DC=biz" für den Connector "CN=SMTP-Standard,CN=Connections,CN=Erste Routinggruppe,CN=Routing Groups,CN=Erste administrative Gruppe,CN=Administrative Groups,CN=Impetus,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ffm,DC=xxx,DC=biz" in Routingtabellen mit dem Zeitstempel 25.01.2012 13:38:46 nicht finden. Microsoft Exchange ignoriert den Quell-Transport-Server.

5016:
Der Active Directory-Topologiedienst konnte keine Route zu dem Connector "CN=dsrv13,CN=Connections,CN=Erste Routinggruppe,CN=Routing Groups,CN=Erste administrative Gruppe,CN=Administrative Groups,CN=xxx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ffm,DC=xxx,DC=biz" in Routingtabellen mit dem Zeitstempel 25.01.2012 13:38:46 erkennen. Dieser Connector wird nicht verwendet.

2937:
Prozess MSExchangeMailboxAssistants.exe (PID=2196). Objekt [CN=xxx\, Achim,OU=Mitarbeiter,DC=ffm,DC=xxx,DC=biz]. Eigenschaft [HomeMTA] ist auf Wert [ffm.xxx.biz/Configuration/Deleted Objects/Microsoft MTA
DEL:f9e74536-34e4-41ee-944a-7cedf8ea2917] festgelegt und zeigt auf den Container "Gelöschte Objekte" in Active Directory. Diese Eigenschaft muss so schnell wie möglich korrigiert werden.

#27 RobertWi

RobertWi

    Expert Member

  • 4.987 Beiträge

 

Geschrieben 25. Januar 2012 - 14:15

Such Dir bei einem fehlerfreien Benutzer per ADSIEdit oder Attribute-Editor den korrekten "HomeMTA"-Wert raus und korrigiere ihn auf gleichem Wege bei den Benutzer, die im Event-Log auftauchen.

Tipp: Zwei Stunden Try&Error können 10 Minuten lesen im Technet sparen!


#28 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 14:25

ok habe ich mit angefangen. Ist wirklich einheitlich falsch.
Was wird dadurch denn umgestellt ?

So wie ich das sehe, ist das ja eine Leiche aus einer "fehlerhaften" Migration. Die Fehler sagen ja auch teilweise aus, dass der Pfad nicht mehr gefunden wird - Pfad auf ein altes System.
Darunter sind auch die alten Routinggruppen für die Migration und andere Objekte.
Posftächer waren es lediglich 4 an denen der Fehler angezeigt wurde.

#29 RobertWi

RobertWi

    Expert Member

  • 4.987 Beiträge

 

Geschrieben 25. Januar 2012 - 14:29

Das zeigt nicht nur auf den alten Pfad, das zeigt auf einen gelöschten Pfad.

Ich denke, da ist beim Verschieben der Postfächer was nicht ganz richtig gemacht worden. Könnte zum Beispiel das Ergebnis einer PST-Migration sein.

Tipp: Zwei Stunden Try&Error können 10 Minuten lesen im Technet sparen!


#30 PowerShellAdmin

PowerShellAdmin

    Board Veteran

  • 1.135 Beiträge

 

Geschrieben 25. Januar 2012 - 14:38

*schwitz* wie kritisch ist das Ganze zu betrachten. Korrigieren ist ja kein Problem. Im Eventlog wird nur sporadisch das betroffende Konto angezeigt.
Per Powershell kann ich alle Userattribute schnell korrigieren - mache ich aber morgen in Ruhe und nicht jetzt in der Aufregung.


Folgende Meldungen irritieren mich aber noch, sollte ich hier den Wert auf den aktuellen Server (PSRV15 und nicht PSRV07) editieren und gut ?
2937:
Prozess edgetransport.exe () (PID=1136). Objekt [CN=Erste Routinggruppe,CN=Routing Groups,CN=Erste administrative Gruppe,CN=Administrative Groups,CN=xxx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ffm,DC=xxx,DC=biz]. Eigenschaft [RoutingMasterDN] ist auf Wert [PSRV07
DEL:d4b7e06c-7fbc-4578-89cf-e6e825a34e3a] festgelegt und zeigt auf den Container "Gelöschte Objekte" in Active Directory. Diese Eigenschaft muss so schnell wie möglich korrigiert werden.

Und was mache ich hiermit ?
2159:
Prozess edgetransport.exe () (PID=1136). Fehler bei der Überprüfung des in PSRV01.ffm.xxx.biz gelesenen Konfigurationsobjekts CN=PSRV15-PSRV07,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=xxx,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ffm,DC=xxx,DC=biz. Es wird aus dem Resultset ausgeschlossen. Legen Sie den Ereignisprotokolliergrad für die Kategorie 'Überprüfung' auf 'Maximum' fest, um zusätzliche Ereignisse zu jedem Fehler zu erfassen.