Jump to content

RC<-->RC

Members
  • Gesamte Inhalte

    32
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

0 Neutral

Über RC<-->RC

  • Rang
    Newbie

Letzte Besucher des Profils

56 Profilaufrufe
  1. Moin Norbert, zum einen, vielen dank für die PS. Hatte das wohl bei der Sequentiellen Abarbeitung 1.Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" 2. Set-Mailbox “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” -Arbitration -Management:$true Einfach nach der Fehlermeldung der 1. PS nicht ausprobiert. Also Danke Zum anderen, Knackpunkt: Naja, ich finde die Öffentlichen Ordner aus 2010 auf 2016 schon ein bisschen mehr Tricky als nur Mailpostfächer von A,B,C,D,E zu Z zu verschieben Gern kannst du da einer anderen Meinung sein :-D Grüsse, Rolf ! Habe im übrigen noch 2 Fehler festgestellt :-( Zum einen gibt es wohl ein Kerberos Problem was die Warteschlangenanzeige betrifft, wofür ich bisher noch keine Lösung gefunden habe : Zum anderen wird desöferten der Transportdienst nicht gestartet nach einem Neustart: Konfiguation hierbei ist : Starttyp:Automatisch Anmeldung : Konto: Netzwerkdienst Wiederherstellung: erster, zweiter, weitere Fehler: jeweils Dienst neu starten. Trotzdem bleibt der Dienststatus beendet. Wie gesagt, bisher wie mir aufgefallen ist, immer nach einem Neustart. Sobald manuell gestartet, bleibt er auch an ! Werde selbstverständlich recherchieren, aber wenn jemand eine sofortige Antwort dazu hat, werde ich der sehr gern nach gehen Grüsse, Rolf !
  2. UPDATE: Enable-Mailbox -Arbitration -Identity "Migration.8f3e7716-2011-43e4-96b1-aba62d229136" Dieser Task unterstützt keine Empfänger dieses Typs. Der angegebene Empfänger ist vom Typ UserMailbox Kann ich jetzt nicht so richtig nachvollziehen :-( Erstellt wurde die Migrationsmailbox ja vom Setup des Exchange !
  3. Die Lösung wird sein, alle Postfächer nach und nach in den jeweiligen Standorten auf den neuen Exchange 2016 umzuziehen, die alten Exchanger aus dem AD zu kratzen, und die DCs runter zu stufen um diese folglich genau so aus dem AD zu werfen Knackpunkt nach dem Umziehen der Postfächer werden die Öffentlichen Ordner sein, die auf den neuen Exchange Migriert werden müssen. Aber Frankysweb hat dazu sehr sehr gute Schritt für Schritt Anleitungen, die ich im Testnetz recht gut nachempfinden konnte Ein Problem habe ich dann doch noch. Und zwar das Migrationsbatch für Postfächer. In der ECP unter Migration erstellen, beschreibt er mir, das meine Organisation kein gültiges Migrationspostfach besitzt. Wie Franky hier folglich richtig beschreibt https://www.frankysweb.de/exchange-2016-systempostfaecher-neu-erstellen/ sind die Systempostfächer nicht richtig ausgewiesen. Aber über die Befehle : get-mailbox -Arbitration get-mailbox -AuditLog werden alle richtig angezeigt. Sie sind im AD unter Users auch vollständig. Auch das Migrationspostfach. Hatte diese auch schon wie Franky beschreibt neu angelegt ! über einen New-Moverequest Per Shell funktioniert das verschieben auf den neuen Exchange tadellos !
  4. Hallo. Ich habe 2 VMs im Hyper V. Eine davon startet sofort im Erweiterten Sitzungsmodus. Die andere Nicht, also nicht sofort Na circa genau 8-9 Minuten bietet mir die andere VM dann an, mich im erweiterten Sitzungsmodus anmelden zu können. Melde ich mich ohne erweiterten Sitzungsmodus an, kann ich weder die LAN Einstellung noch die Systemsteuerung öffnen, erst sobald ich den Erweiterten Sitzungsmodus starten kann, funktioniert wieder alles Tadellos... Kennt jemand das Phänomen der verzögerten Sitzungserweiterung ? Die ganzen Einstellungen zum Erweiterten Sitzungsmodus in Hyper-V sind richtig ! Bilde mir ein, das dies erst nach der Installation des Exchange 2016 anfing ! LG. Rolf !
  5. Ja :-D Das erübrigt sich aber dann mit den DCs, da dort schon neue stehen, aber auf den DCs mit 2008 fälschlicherweise auch der Exchange installiert wurde Noch eine kleine andere Frage, die ich im VM Umfeld zu Hyper V habe: Ich habe 2 VMs im Hyper V. Eine davon startet sofort im Erweiterten Sitzungsmodus. Die andere Nicht, also nicht sofort Na circa genau 8-9 Minuten bietet mir die andere VM dann an, mich im erweiterten Sitzungsmodus anmelden zu können. Melde ich mich ohne erweiterten Sitzungsmodus an, kann ich weder die LAN Einstellung noch die Systemsteuerung öffnen, erst sobald ich den Erweiterten Sitzungsmodus starten kann, funktioniert wieder alles Tadellos... Komisch oder ? Die ganzen Einstellungen zum Erweiterten Sitzungsmodus in Hyper-V sind richtig !
  6. UPDATE : ES FUNKTIONIERT :-D Diese KACK (entschuldigt diesen Ausdruck) Microsoft.Exchange.Services.Json.dll habe ich einfach aus der CU6 DVD gesucht und in das BIN Verzeichnis des EXCHANGE Server kopiert. Danach in der CLIENTACCESS und HTTPPROXY in der SharedWebConfig folgendes hinzugefügt : <dependentAssembly> <assemblyIdentity name="Microsoft.Exchange.Services.Json" publicKeyToken="31bf3856ad364e35" culture="neutral" /> <codeBase version="15.0.0.0" href="file:///D:\Exchange-Server\\bin\Microsoft.Exchange.Services.Json.dll" /> </dependentAssembly> Genau das, was er eben vergeblich nicht finden konnte. Man sollte einfach mal das machen was da steht :-D Trotzdem Vielen dank für eurer Feedback und eure Hilfen !
  7. UPDATE: Hat nun doch funktioniert : Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint Set-AuthConfig –PublishCertificate Zertifikate werden nun wieder richtig angezeigt ohne Fehler ! Die UpdateCAS und die UpdateConfigfiles.ps1 habe ich auch ausgeführt nachdem ich den IIS neugestartet habe. Auch habe ich den Server neu gestartet ! Leider ohne Erfolg ! :-( Gibt es weitere Möglichkeiten ? Bisher habe ich noch das Framework 4.7.1 drauf, das müsste ich noch auf 4.6.2 machen richtig ? Der Fehler bleibt der gleiche ... Ereignis ID 1309 ASP.NET 4.0.30319.0 Application Virtual Path: /owa Application Path: D:\Exchange-Server\ClientAccess\owa\ Process ID: 7020 Process name: w3wp.exe Account name: NT-AUTORITÄT\SYSTEM Die Datei oder Assembly "Microsoft.Exchange.Services.Json, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden. bei System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) bei
  8. Moin Moin Norbert Ich habe die 3 Exchange Zertifikate : Das erste für den SMTP Dienst gegenüber anderen Exchange Servern nehm ich an Das Zweite gegenüber der Authentifizierung der Benutzer (Dienste IMAP,POP und IIS und SMPT) Keines der Zertifikate enthält den Fingerabdruck den er gern möchte zur Veröffentlichung ! Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint Ein spezieller RPC-Fehler ist auf Server SERVERNAME aufgetreten: Das Zertifikat mit dem Fingerabdruck '7685D2B5CCB4E278CB416218E719072A3DCB892D' wurde nicht gefunden. Das Exchange Server Auth Certificate existiert ja bereits ! Was muss ich denn tun, das er nicht mehr nach dem nicht mehr vorhandenen Zertifikat sucht, um dann per Befehl : Set-AuthConfig -PublishCertificate diese Fehlermeldung nicht mehr zu erhalten ? : "Das Zertifikat, das als Nächstes verwendet werden kann, muss eingerichtet sein, bevor es veröffentlicht werden kann" Vielen dank zunächst für deine/eure Hilfreichen Links, aber so ganz hilft es mir leider nicht weiter, da ich damit zwar neue Zertifikate erstelle, sich der Fehler nach einem nicht mehr vorhanden Zertifikat, was er möchte nicht erübrigt :-(
  9. Nach Erstellung des neuen Zertifikats und der Eingabe von Set-AuthConfig –PublishCertificate kommt nun folgender Fehler ?! Das Zertifikat, das als Nächstes verwendet werden kann, muss eingerichtet sein, bevor es veröffentlicht werden kann. Puh, da muss ich mich wohl nochmal ein wenig belesen
  10. Gut, den gleichen Fehler wie auf der Seite bekomm ich auch :-( Ich werd es mal probieren und berichte !
  11. könntest du mir das näher erklären ? Ich mach das CU7 denk ich jetzt mal drüber und mach die Framework 4.7.1 weg und die 4.6.2 drauf, denk ich
  12. Lad es mir gerade, ohne für mich verifiziert zu haben, ob es mit 2008 ohne R2 funktioniert
  13. Moin Moin, habe die UpdateCas.ps1 wie zuvor schon erwähnt ausprobiert ! Ohne Erfolg ! Aufgefallen ist mir, das dass Framework 4.7.1 schon drauf ist, und nicht wie fälschlicherweise behauptet, die 4.0 ! Zudem kann ich nicht auf die CU8 , da die DomänenFunktionsEbene mit dem CU8 auf auf 2k8 R2 Steigt, und ich noch 2 Domänencontroller in anderen Standorten habe, die leider nur Win Server 2008 inne haben. Somit kann ich das CU8 nicht einfach drauf machen, sondern müsste diese erst auf R2 bringen ! Bin kurz davor die Maschine einfach neu zu machen, und von vorn zu beginnen, anstatt noch ewig zu suchen :-( Zumal noch nicht viel drauf ist, und das ding ja über den ADSI recht schnell wieder raus gekehrt ist ! Also die Postfächer sind alle von mir geerbte Test Administratoren ( Im AD von meinem Account kopiert) Also die AD Konten stammen alle von meinem Konto ab, falls du das meinst ?! @MRCOCKTEIL ExchangeLegacyDN ist korrekt? ADCDisabledMail Flag? Die Self Berechtigungen stimmen? Puhh, damit kann ich leider nix anfangen, das müsst ich mir erst anschauen, was du damit überhapt meinst, es sei denn du erklärst es mir gern, dann les ich es gespannt, und verinnerliche gleichzeitig
  14. Wie gesagt, der root server sowie die vms sind lizenziert. Der exchange bisher nicht. Bedenken habe ich da aber keine. Es ist eben nur komisch das es die owa unter den Postfächern des 2016 betrifft. Und warum sollte es unter der CU6 nicht auch laufen?! Ich werd die Updates erst mal drüber bügeln, aber bin keiner grossen Hoffnung. Vielleicht gibt es ja noch andere Ideen. Wäre natürlich weiteren Erfahrungen sehr dankbar.
  15. Dann hab ich sie wohl nicht richtig verstanden Der 2012R2 ist lizenziert. Der exchange bisher nicht.
×