henryy

Moin, muss ich bei einer systemstate Rücksicherung (Windows Server Sicherung) eines 2012 R2 DCs (2 DCs in der Domäne) nach einem authoritative restore noch Ntdsutil ausführen und dort noch authoritative restore ausführen? wahrscheinlich ja, sonst wird durch den zweiten DC wieder alles auf den Stand vor dem recovery gebracht Und welches "Argument" gebe ich dann bei Ntdsutil ein um das AD inklusive Schema Änderungen auf einen früheren Stand zu setzen und auch zu halten? authoritative restore: restore subtree "dc=Domäne,dc=de

ja hatte ich auch schon überlegt aber auf einen defekten cu4 jetzt n8chmal cu8 installieren und hoffen das es besser ist und nicht dann noch andere fehler auftauchen finde ich nicht so verlockend. dann doch lieber deinstallieren und gleich cu8 drauf. der werver war eh noch nicht produktiv und hatte noch keine riesen konfig. ich weiss nur nicht ob die deinstallation dann wieder was nach sich zieht mit resten im ad etc

CU4 lief problemlos durch und wenn man jetzt noch Emails verschicken könnte, wäre alles super :schreck: Den tag vergeblich damit verbracht den Exchange zum internen Mailversand zu bringen. Wenn aus OWA(im LAN) eine Mail versendet wird an einen anderen user im LAN, dann geht die Mail nicht aus dem Postausgang sondern verschwindet direkt in den Ordner Entwürfe. Scheint ein "bekanntes" Problem zu sein bei update auf SP1. Da freut man sich ja auf jedes bevorstehende CU update;) Ich werde den Exchange jetzt deinstalieren und dann gleich CU8 neu installieren. Muss noch mehr getan werden als uninstall und die Mailboxen auszuhängen und spricht was dagegen danach einen neuen 2012 mit gleicher IP und gleichem Namen als Exchange auszusetzen ? Die uninstall Routine sollte doch alle Objekte aus dem AD entfernen oder? Get-Mailbox|Disable-Mailbox Get-Mailbox -Arbitration|Disable-Mailbox -Arbitration -DisableLastArbitrationMailboxAllowed Setup /Mode:Uninstall /IAcceptExchangeServerLicenseTerms

Oh man, Je mehr ich drüber nachdenke, je "sinnfreier" kommt einem das mit dem RTM-CU2-CU4-CU6-CU8 vor. Das würde 4 "neu" installationen des Exchange bedeuten. Direkt auf CU8 ist wahrscheinlich echt happig, aber sollte doch trotzdem möglich sein Scheinbar geht RTM-CU4, was ja wenigstens schonmal CU2 überspringt https://social.technet.microsoft.com/Forums/de-DE/22227eb3-75c2-41d9-ac9f-4251c05df8ce/exchange-2013-rtm-direkt-updaten-auf-cu6?forum=exchange_serverde

ja der Sprung ist mir auch zu heikel. Ich werden erstmal auf CU2 und dann zumindest noch auf CU4 (SP1) gehen. Überall findet man Anleitungen das man vorher das Schema selber updaten muss. Bist du sicher das man nur das update durchlaufen lässt und das dort automatisch passiert?

Moin, warum gerade diese Reihenfolge? also RTM-CU3-CU5-CU7-CU8 ? Die Verbindung mit Q: How long is a CU supported? ist mir nicht ganz klar. was bedeutet das genau? Ich habe irgendwo gelesen das MS nur zwei CU Sprünge supported, aber dann wäre zumindest RTM-CU3 nicht wirklich in diesem Rahmen

Moin, ich habe hier einen Exchange 2013 ohne CU, also "CU0";). Ich würde gerne das CU8, welches ja kumulativ ist, einspielen. Bin mir aber nicht sicher ob vorher ein schema update gemacht werden muss, oder ob das vom CU übernommen wird bzw ob es überhaupt ratsam ist gleich auf CU8 zu gehen oder vielleicht sogar einen zwischenschritt bzw zumindest SP1 installieren Wenn ich das richtig verstanden habe muss ich vorher selber ein schema update machen, wenn der Exchange auf einem Stand vor dem CU6 ist, was in meinem falle ja zutrifft. ist das so?

Moin, es waren tatsächlich die Deltasperrlisten. Der Haken war nicht gesetzt bei "Deltasperrlisten Veröffentlichen". Wundert mich nur das trotzdem ja am Anfang eine einsame Delta veröffentlicht wurde, welche dann ja abgelaufen war und aufgrund dessen die Sperrlisten Warnung kam Was ist ein "guter" Wert für die veröffentlichungs Intervalle bei den CRL und Delta CRLs? 1x die Woche und einmal am Tag erscheint mir recht hoch. Genutzt wird das ja hauptsächlich intern und für eine Zweigstelle über ein VPN. Ein riesen Dank an alle die mit guten Links etc geholfen haben und ins besonderen den dunklen Mann.... Du hast ein Bier bei mir gut;) Ohne deine Hinweise auf die Delta, hätte ich das Problem wahrscheinlich nicht lösen können

Moin, es sieht wirklich nach einem Problem mit der Delta Sperrliste aus. Die HTTP Delta CRL ist abgelaufen. Mir ist aber nicht klar warum...? Im Anhang ist die abgelaufene Delta und die Sperrlisten "Konfig" zu sehen

Moin, danke für die Infos. Ja es sieht so aus als wenn MS den Zugriff über RDWEB zum Standard gemacht hat und DNS RR wirklich keinen Sinn mehr macht. Problem was ich jetzt noch habe ist, dass selbst mit dem Registry Tweak es nicht funktioniert sich über mstsc an der Farm anzumelden. Es ändert zwar das verhalten, das jetzt wenisgtens der Broker versucht an die farm weiterzuleiten aber dann kommt die fehlermeldung aus dem angehängten Bild, das der farmname erwartet wird. Idee warum das nicht klappt mit dem regitsry eintrag? Vielleicht funktioniert das nur mit VDI und nicht mit RDS Host Umgebung...... In den meisten Threads wurde das mit VDI gemacht Leider bruache ich die verbindung über mstsc, da Zugriff über non Domain Clients ohne internetzugang möglich sein soll und über RDWEB müssten die user sich zweimal mit Passwort anmelden. SSO ist wpohl nur innerhalb der Domäne möglich. Ich habe mir jetzt die RDP aus RDWEB kopiert und auf den non Domain Client kopiert. Darüber klappt der mstsc Zugriff auf die farm. Die Verbindung wird innerhalb 2 sec aufgebaut. Ich bin mir nur nicht sicher ob das nicht doch irgednwann zu Problemem führen kann aber eigentlich sollte das doch so funktionieren oder übersehe ich da grad was?

Moin, update: Bisher hatte ich die Farm über DNS Round Robin "veröffentlicht". Das habe ich jetzt mal entfernt und folgendes gemacht: @ den dunklen mann;) Mir ist grad ein Post von dir über den Weg gelaufen http://www.mcseboard.de/topic/196586-w2012-r2-rds-farm-zertifikat/ indem du [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings] "DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection" angibst um in einer normalen RDP Sitzung über den Broker die farm zu erreichen. Ist das im Grunde eine Umgehung von DNS Round Robin? Sieht für mich nach einer möglichen Lösung meines Problems aus, aber leider erscheint dann die Meldung aus dem screenshot. Er will den Farm Namen, aber wie soll das ohne Round Robin gehen?

Moin, Bei einer Verbindung über den Farm Namen dauert der RDP verbindungsaufbau zwischen 15-30 sec und hängt meist sehr lange bei "Remoteverbindung wird gesichert". Die RDP wird durch ein Zertifikat von der internen CA gesichert Bei Aufruf über mstsc /admin über den normalen Server Namen geht der Verbindungsaufbau innerhalb von 1-2 sec. Dann erscheint aber auch kein schloss Symbol in der RDP leiste das die Verbindung über ein Zertifikat gesichert ist. Das es etwas länger dauert ist normal denke ich, da ja beim ansprechen über die Farm mehrerer "Verbindungspartner" beim Aufbau der Verbindung beteiligt sind, aber das muss doch eigentlich schneller gehen oder was denkt ihr? Kann das noch beschleunigt werden oder ist das vielleicht sogar "normal"?

Moin, update: bei non Domain Clients über gpedit unter WindowsEinstellungen-Sicherheitseinstellungen-Richtlinie für öffentliche Schlüssel-Einstellungen für dir Überprüfung des Zertifikat Pfades gibt es im letzten reiter "Sperrung" den Punkt "längere Gültigkeitsdauer von sperrlisten und OCSP-Antworten zulassen". Wenn ich diese Richtlinie definiere und einen wert grösser 76 Stunden einstelle dann kommt keine Sperrlisten Warnung mehr. Wenn ich mir die interne CA Sperrliste ansehe dann besitz die eine Gültigkeit von 8 Tagen. Für mich sieht es so aus als wenn das für Windows 8.1 zulange ist....? Allerdings verstehe ich nicht ganz wieso dann bei 76 Stunden keine Warnung mehr kommt, denn meine Sperrliste hat eine Gültigkeit von Montag 27.4 bis Dienstag 5.5, also noch 6 Tage sprich noch ca 144 Stunden. Erwartet hätte ich jetzt das sich das mit den 76 Stunden deckt. 2 Stunden später muss man dann von 76 auf 78 stunden im Client ändern um keine Sperrprüfungswarnung zu erhalten. Mir ist nicht klar nach welchem Zeitwert der Client sich da richtet Weiß jemand warum das so ist?

Moin, offizielles Zertifikat scheitert daran, dass die betreffenden non Domain Clients keinen Zugang zum Internet haben und wir eh eine eigene CA nutzen wollten für kommende Projekte. Ich konnte das Problem etwas eingrenzen. Es scheint in Zusammenhang mit der RDS Farm bzw dem RDS SAN Zertifikat aufzutreten. Wenn ich einen RDS Host über seinen srv00... Namen über RDP vom non Domain Client Aufrufe kommt keine Sperrlisten Warnung. Nehme ich aber den Farm Namen farm.Domäne.de, dann kommt diese Warnung. Obwohl ich ja erst in diesem RDS Farm SAN Zertifikat die Sperrlisten über HTTP erreichbar gemacht habe..?? Auch bei anderen Servern(non RDS Hosts) kommt mit einem non Domain Client über RDP keine Sperrlisten Warnung Das erschließt sich mir gerade gar nicht warum das so ist update: über den normalen Server Namen nimmt er ein anderes RDP Zertifikat (RDP Vorlage wird über GPO verteilt und wurde grade erneuert und somit liegt dort auch die Sperrliste über HTTP vor). Liegt wohl an dem SAN Zertifikat...

Hi, Delta Sperrlisten ist in den Eigenschaften der Domäne-CA unter Erweiterungen bei LDAP der haken bei "Deltasperren an diesem Ort veröffentlichen" gesetzt. Bei HTTP kann ich den Haken nicht setzen weil ausgegraut. ?? IIS Double escaping hatte ich schon erlaubt. Vorübergehende "Lösung": In den Einstellungen des RDP 8.0 Clients unter Erweitert-Serverauthentifizierung den Schalter auf "verbinden und keine Warnung anzeigen" lässt die Zertifikatswarnung nicht mehr aufpoppen, aber glücklich bin ich damit nicht

Hi @Jan, das ist ein wirklich guter Link zu dem Thema. leider komme ich aber der lösung nicht näher über certutil -URL ...... bekomme ich die Ausgabe wie in dem Bildanhang Sieht für mich erstmal so aus, als wenn der Client die CRL über HTTP abrufen kann. Die Warnung über RDP bleibt trotzdem. Prüft der RDP Client vielleicht immer nur über LDAP? IE Einstellungen sind auch korrekt und im IIS auch der anonyme Zugriff auf die HTTP Seite ist erlaubt Übersehe ich noch etwas oder noch eine Idee?

Moin, die Clients sind zu testzwecken im gleichen LAN wie die Domänen Clients und können über DNS eigentlich auch alles auflösen. Zumindest funktioniert der Aufruf über den IE und download der CRL über http://servername.interne.domäne/CertEnroll/domäne-CA.crl certutil -verify http://servername.interne.domäne/CertEnroll/domäne-CA.crl führt zu einem Fehler "Die Syntax für den Dateinamen ist falsch" @ jan dein link führt leider ins MS Nirvana, aber ich habe nachträglich einen sperrlistenverteilpunkt eingerichtet auf der internen CA und ein neues RDP Zertifikat erstellt in dem dann auch diese HTTP Adresse aufgeführt wird. allerdings erst unter der Standard LDAP CRL(welche Non Domänen Clients ja nicht erreichen können). Vielleicht wollen die Clients immer LDAP nutzen bei RDP?? Oder muss ich vielleicht auch noch einmal das Root CA neu erstellen, denn dort ist die CRL über HTTP noch nicht eingetragen

Moin, in einer 2K12R2 RDS Umgebung mit interner CA, gibt es eine Außenstelle die mit Windows 8.1 non Domain Clients über RDP durch ein VPN auf eine RDS Farm zugreifen soll. Das Root Zertifikat, wie auch das durch die interne CA ausgestellte SAN Zertifikat (mit den RDS Namen), wurde in die Clients importiert. Die "normalen" Zertifikatswarnungen sind verschwunden, bis auf eben dieser nervige "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden" Ich kann die zertifikatssperrliste vom Client über HTTP runterladen aber für mich sieht es so aus als wenn diese Prüfung nur über LDAP funktioniert, also auch wenn ich einen non Domänen Testclient im selben LAN habe kommt die Fehlermeldung. Auch das herunterdrehen der Sicherheitsstufe auf den RDS Hosts von SSL/Aushandeln auf "RDP-Sicherheitsstufe", welches in einigen Threads als "Lösung" gebracht wird, hat nichts gebracht Hat jemand eine Idee diese Meldung los zu werden?

Moin, pst weil der Exchange 2013 in einer neuen Domäne läuft. Bisher habe ich da keine wirklich gangbare Möglichkeit gesehen die eine Migration Domänenübergreifend macht, aber wenn jemand eine gute Idee hat bin ich natürlich auch da offen für p.s die Backup excec .exe habe ich mir mittlerweile über ein befreundetest systemhaus besorgen können und werde das mal testen und berichten.

Ok, danke! :thumb1:

Moin, was ist wenn die VM schon in der Domäne läuft? Also Sysprep in der Domäne. Kann ich diese dann immer noch sysprepen und daraus eine "Vorlage" erstellen? Müsste eigentliche gehen, denn durch das Sysprep wird die VM ja in eine Arbeitsgruppe verschoben. Wahrscheinlich muss man sie dann nur per Hand aus dem AD entfernen wenn man den gleichen Namen nochmal nutzen will

Moin, ich möchte einen virtuellen Server (SRV01 wurde schon 1x gesysprept), 2012 Terminalserver mit installierten Programmen und Domänenmitglied, vervielfältigen und unter anderen Namen und IPs in der gleiche Domäne laufen lassen wie SRV01. Das würde wenn ich das richtig sehe nur in VMM 2012 R2 über ein Template gehen weil dort ein sysprep durchgeführt wird. Die normale Clone bzw Export Funktion in Hyper V macht ja leider kein sysprep Was spricht gegen die einfache variante mit SRV01 runterzufahren, VHD kopieren und in einem seperaten Netz hochzufahren, sysprep machen und umbennen in SRV02 und wieder in das produktiv Netz und die domäne holen? Müsste doch in der Reihenfolge funktionieren oder?

Moin, danke für die Antworten. Exmerge hilft mir leider nicht, da 2GB Limit. Das die 2012 Backup exec mies ist kann sein, aber wäre mir egal wenn die Funktion "Wiederherstellung in eine pst" vernünftig funktioniert, da sie wirklich nur für 1 tag für eben genau diese Funktion eingesetzt werden soll. Es sollen die Inhalte der Postfächer aus einem 2003er Exchange in einer neue Domäne (leider nicht innerhalb der selben Domäne) den Mitarbeitern in Ihrem Outlook als Archiv zur Verfügung gestellt werden. Mir scheint es einen versuch wert zu sein den Weg über Backup exec zu gehen, da er in der Theorie recht simpel, schnell und machbar erscheint. Vielleicht nicht der eleganteste weg, aber Not macht erfinderisch;) Hat keiner die .exe oder CD? Was wäre die Alternative? Das alte System von Exchange 2003 auf 2010 Migrieren und dann Export der Postfächer in pst?

Moin, ich suche händeringend ein Installationsmedium für eine ältere Backup Exec Version. Am besten 2012 oder wahrscheinlich geht 2010 auch. leider sind überall nur noch die 2014 Versionen zu bekommen. Die Lizenzen für eine 2014 Version habe ich und diese lässt sich downgraden auf 2012. Hintergrund ist das diese Version Wiederherstellung in pst Dateien einzelner Postfächer aus einem Exchange 2003 machen kann und ich das für die Migration der Postfächer eines 2003 Exchange zu 2013 nutzen möchte. Hast jemand noch eine 2012er rumliegen? Gruß

Moin, ich sehe da kein Problem zwei Hosts direkt mit dem SAN zu verbinden. Momentan habe ich zwei Host redundant an das SAN angebunden. Das MPIO Feature (ohne das sieht man die LUNs doppelt) in 2K12R2 aktiviert und die nötigen MPIO Treiber, dann sieht man auf dem Server auch wirklich nur die jeweiligen LUNs. Falls es doch triftige Gründe gibt dies nicht so zu tun, bin ich natürlich an dem wieso und weshalb sehr interessiert.