wurde migriert?

[RobertWi 81]

Moin,

 

2937: ich habe hier eine migrierte Umgebung, in der ungefähr das gleiche drin steht, wie bei Dir (als ein alter, nicht mehr existierender Server, der gelöscht ist), aber keine Fehler protokolliert. Merkwürdig. Im Prinzip kannst Du den Eintrag aber auch einfach löschen oder den DN des neuen Servers eintragen -> die RG wird eh nicht mehr verwendet, wenn Du kein Ex2003 mehr hast.

 

2159: Schalte die Protokollierung hoch und sieh Dir an, was dann protokolliert wird.

bearbeitet 25. Januar 2012 von RobertWi

[PowerShellAdmin 169]

danke,

 

bzgl. 2159, wie du beschreibst, werde ich das ganze erstmal loggen.

Source: MSExchange ADAccess Event ID: 2159 (Exchange 8.0) - Technet Events And Errors Message Center: Message Details

hier stehen auch weitere informationen:

http://social.technet.microsoft.com/Forums/pl-PL/exchange2010/thread/0eb1c924-63d3-4a2e-a96c-0762a64794cb

 

sobald das Problem gelöst, alle UserAttribute gesetzt, hoffe ich dass alles wieder rund läuft. Das man auch immer über alte Probleme stolpern muss...aber man lernt so wenigstens dazu :)

[PowerShellAdmin 169]

Also bzgl. 2937 habe ich folgenden Artikel gefunden:

MSXFAQ.DE - Event 2937

 

Hier habe ich wie beschrieben überall die HOMEMTA aktualisiert:

Get-Recipient | Update-Recipient

 

Damit hat er alle Benutzer korrigiert - außer einen

 

Allerdings gab es eine Reihe an Fehlern bei öffentlichen Freigaben:

Diese sehen so aus:

Eigenschaftenausdruck "Schwarzes Brett" ist ungültig. Gültige Werte: Zeichenfolgen, die aus den Buchstaben A bis Z (Gro
ß- und Kleinbuchstaben), Zahlen von 0 bis 9, !, #, $, %, , ', *, +, -, /, =, ?, ^, _, `, {, |, } oder ~ bestehen. In ei
nem Alias kann mindestens ein Punkt eingebettet werden, wobei jedoch jedem Punkt mindestens eines der anderen Zeichen v
orausgehen und nachfolgen muss. Unicode-Zeichen von U+00A1 bis U+00FF sind ebenfalls in einem Alias gültig, sie werden
jedoch in der aus einem derartigen Alias erstellten E-Mail-Adresse mit möglichst guter Übereinstimmung einer US-ASCII-Z
eichenfolge zugeordnet..
   + CategoryInfo          : NotSpecified: (ffm.xxx.biz...Schwarzes Brett:ADObjectId) [update-Recipient], DataVal
  idationException
   + FullyQualifiedErrorId : A8231D98,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

Die öffentlichen Ordner werden so auch garnicht genutzt. Wir haben da lediglich ein Telefonbuch das wir noch verwenden. Der Rest sind "Altlasten".

[NorbertFe 2.045]

Schwarzes Brett beinhaltet im Alias wahrscheinlich ein Space. ;) Das ist in Exchange 2007/2010 nicht mehr supported. Also ersetz das und es wird funktionieren.

 

Bye

Norbert

[PowerShellAdmin 169]

Schwarzes Brett beinhaltet im Alias wahrscheinlich ein Space. ;) Das ist in Exchange 2007/2010 nicht mehr supported. Also ersetz das und es wird funktionieren.

 

Bye

Norbert

 

Danke für deinen Tipp, du hast scheinbar recht, trifft auf alle Fälle zu. Werde das anpassen und überprüfen.

 

Grüße :thumb1:

[PowerShellAdmin 169]

Schwarzes Brett beinhaltet im Alias wahrscheinlich ein Space. ;) Das ist in Exchange 2007/2010 nicht mehr supported. Also ersetz das und es wird funktionieren.

 

Bye

Norbert

 

Danke für deinen Tipp, du hast scheinbar recht, trifft auf alle Fälle zu. Werde das anpassen und überprüfen.

 

Grüße :thumb1:

 

edit:

bestehen noch 2 Probleme, über die Eigenschaften sehe ich dass Leerzeichen vorhanden sind. Darf diese aber nicht ändern:

Eigenschaftenausdruck "Offlineadressbuch - Erste administrative Gruppe" ist ungültig. Gültige Werte: Zeichenfolgen, die
aus den Buchstaben A bis Z (Groß- und Kleinbuchstaben), Zahlen von 0 bis 9, !, #, $, %, , ', *, +, -, /, =, ?, ^, _, `
, {, |, } oder ~ bestehen. In einem Alias kann mindestens ein Punkt eingebettet werden, wobei jedoch jedem Punkt mindes
tens eines der anderen Zeichen vorausgehen und nachfolgen muss. Unicode-Zeichen von U+00A1 bis U+00FF sind ebenfalls in
einem Alias gültig, sie werden jedoch in der aus einem derartigen Alias erstellten E-Mail-Adresse mit möglichst guter
Übereinstimmung einer US-ASCII-Zeichenfolge zugeordnet..
   + CategoryInfo          : NotSpecified: (ffm.xxx.biz...strative Gruppe:ADObjectId) [update-Recipient], DataVal
  idationException
   + FullyQualifiedErrorId : 157C9F09,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

 

 

Eigenschaftenausdruck "Schedule+ Zeitplaninformationen - Erste administrative Gruppe" ist ungültig. Gültige Werte: Zeic
henfolgen, die aus den Buchstaben A bis Z (Groß- und Kleinbuchstaben), Zahlen von 0 bis 9, !, #, $, %, , ', *, +, -, /,
=, ?, ^, _, `, {, |, } oder ~ bestehen. In einem Alias kann mindestens ein Punkt eingebettet werden, wobei jedoch jede
m Punkt mindestens eines der anderen Zeichen vorausgehen und nachfolgen muss. Unicode-Zeichen von U+00A1 bis U+00FF sin
d ebenfalls in einem Alias gültig, sie werden jedoch in der aus einem derartigen Alias erstellten E-Mail-Adresse mit mö
glichst guter Übereinstimmung einer US-ASCII-Zeichenfolge zugeordnet..
   + CategoryInfo          : NotSpecified: (ffm.xxx.biz...strative Gruppe:ADObjectId) [update-Recipient], DataVal
  idationException
   + FullyQualifiedErrorId : 22D620B4,Microsoft.Exchange.Management.RecipientTasks.UpdateRecipient

 

edit2: erledigt: musste nur auf den richtigen Pfad, war an der falschen Stelle :)

[NorbertFe 2.045]

faq-o-matic.net » Exchange-2007-Migration: Alias bereinigen Dürfte deinem Nick nach ja passen.

 

Bye

Norbert

[PowerShellAdmin 169]

faq-o-matic.net » Exchange-2007-Migration: Alias bereinigen Dürfte deinem Nick nach ja passen.

 

Bye

Norbert

 

Da wir nur ~8 Stück hatten ging das Ganze manuell :) Aber danke für den Tipp, konnte die Probleme zwischenzeitlich schon händisch lösen.

[PowerShellAdmin 169]

Fehler 2159

Prozess edgetransport.exe () (PID=1136). Fehler bei der Überprüfung des in PSRV02B.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=xxxCN=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.

 

Ich habe mir im Adsi das Ganze angeschaut, meiner Meinung nach ist das eine Leiche. Und zwar ein Verweis auf einen Sendeconnector im Exchange 2010 (Ist die administrative Gruppe des Ex2010). Ich gehe davon aus, dass es die alte Konfiguration aus der Migration war.

Es ist ein "mxEXchRoutingGroupConnector"

Den Eintrag sollte ich doch ohne weiteres löschen dürfen oder ?

[NorbertFe 2.045]

Wenn du ihn in der EMC siehst, kannst du ihn dort natürlich löschen (bei Nichtbedarf). :)

 

Bye

Norbert

[PowerShellAdmin 169]

Im EMC habe ich allte SMTP Sendeconnectoren entfernt, da ist nur noch unser 1er drinne.

 

Per Adsi sehe ich unseren SMTP Sendeconnector und diesen alten Verweis auf den Groupconnector, ist also kein SMTP Connector.

Bei MS habe ich folgende Seite gefunden:

http://technet.microsoft.com/de-de/library/aa998645.aspx

 

Habe mein Identity Paramter entsprechend angepasst (Habe einfach den distinguishedName zerstückelt).

PS:

Remove-RoutingGroupConnector -Identity "
Exchange Administrative Group (FYDIBOHF23SPDLT)\Exchange Routing Group (DWBGZMFD01QNBJR)\PSRV15-PSRV07" -DomainController psrv02b.xxx.biz

Benötigen tue ich ihn ja nicht mehr, oder spricht was dagegen?

[NorbertFe 2.045]

Routinggroupconnnectoren kannst du nur per Powershell konfigurieren/administrieren.

get-routinggroupconnector | remove-routinggroupconnector

 

Hilft weiter, da deine alte Routinggroup eh nicht mehr vorhanden ist.

 

Bye

Norbert

[PowerShellAdmin 169]

Routinggroupconnnectoren kannst du nur per Powershell konfigurieren/administrieren.

get-routinggroupconnector | remove-routinggroupconnector

 

Hilft weiter, da deine alte Routinggroup eh nicht mehr vorhanden ist.

 

Bye

Norbert

 

Hey,

das hatte ich ja in meinen vorrangegangenen Post ebenfalls beschrieben, hat sich womöglich überschnitten.

Im Testsystem waren anschließend übrigens auch keine Einträge mehr im ADSI vorhanden. So wies sein soll.

 

Grüße :)

[NorbertFe 2.045]

Ja, aber mein Befehl ist kürzer. ;)

 

Bye

Norbert

[PowerShellAdmin 169]

Ja, aber mein Befehl ist kürzer. ;)

 

Bye

Norbert

 

Da hast du recht, in dem Fall ok.

Aber dein Befehl entfernt sämtliche Routinggruppen, nicht nur eine ;)