henryy

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.

Hier der Auszug aus dem Clusterbericht: Permanente Reservierung für Speicherplatz überprüfen Beschreibung: Überprüfen Sie, ob für Speicher die SCSI-3-Befehle für permanente Reservierung unterstützt werden, die von Speicherplätzen zur Unterstützung von Clustern benötigt werden. Anfang: 02.12.2014 17:45:44. Es wird überprüft, ob es tatsächlich weder permanente Reservierungen noch Registrierungsschlüssel für den Testdatenträger "1" vom Knoten "Host1......." gibt. Fehler. Auf dem Testdatenträger "1" vom Knoten "Host1......." gibt es keine permanente Reservierung, nachdem der Registierungsschlüssel "0x10000000b" des Reservierungsbesitzers erfolgreich aktualisiert wurde. Es wird überprüft, ob es tatsächlich weder permanente Reservierungen noch Registrierungsschlüssel für den Testdatenträger "0" vom Knoten "Host1......" gibt. Die PR-Aktion (Persistent Reservation, permanente Reservierung) RESERVE für den Testdatenträger "0" wird vom Knoten "Host1....." mit dem Schlüssel "0xa" ausgegeben. Fehler. Auf dem Testdatenträger "0" vom Knoten "Host1......." gibt es keine permanente Reservierung, nachdem der Registierungsschlüssel "0xb" des Reservierungsbesitzers erfolgreich aktualisiert wurde. Ende: 02.12.2014 17:45:45. Vom Testdatenträger "1" werden keine SCSI - 3 - Befehle für permanente Reservierung unterstützt, die von Clusterspeicherpools benötigt werden, die das Subsystem für Speicherplätze verwenden. Für einige Speichergeräte sind spezielle Firmwareversionen oder Einstellungen erforderlich, damit sie für Failovercluster funktionsfähig sind. Wenden Sie sich an den Speicheradministrator oder Speicherlieferanten, wenn Sie Informationen zum Konfigurieren des Speichers benötigen, damit er ordnungsgemäß mit Failoverclustern funktioniert, die Speicherplätze verwenden. Permanente SCSI-3-Reservierung überprüfen Beschreibung: Überprüft, ob der Speicher die SCSI-3-Befehle für permanente Reservierung unterstützt. Anfang: 02.12.2014 17:45:03. Die permanente Reservierung wird vom Testdatenträger "0" unterstützt. Die permanente Reservierung wird vom Testdatenträger "1" unterstützt. Ende: 02.12.2014 17:45:07. Sagt das SCSI-3 permanente Reservierung erstmal unterstützt ist, aber eben nicht für Clusterspeicherpools . Ich vermute damit ist im Failovercluster-Manager Speicher-Pools gemeint und hört sich nach dem Dateiserverfeature Storage pools(unterschiedliche Arten von Festplatten zu einem Pool fassen) an. Es sollen aber keine Storage Pools eingesetzt werden, sondern die LUNs sollen als Freigegebene Clustervolumes bereitgestellt werden Ist geklärt und kann zu. Danke für die Antworten. Für alle die es interessiert: Die Warnung kann in dem Fall ignoriert werden, da es sich wie gedacht um die Storage Spaces/Pools dreht und diese in der genannten Umgebung keine Verwendung finden. Bei den HP 2040 ist die SCSI-3 permanente Reservierung im Standard schon aktiv (bei relativ aktueller Firmware). @zahni einen FC Switch kann, aber muss man nicht einsetzen. Macht natürlich Sinn wenn mehr als 4 Hosts einsetzt, aber das ist in dieser Umgebung nicht der Fall.

Moin, danke für den Link Es ist der Datenträger (LUN) der für den Cluster genutzt werden sollen um zb VMs darauf abzulegen. Es wird nur eine Warnung ausgegeben beim Test "Permanente Reservierung für Speicherplatz überprüfen". Der gleich darauf folgende Test "Permanente SCSI-3-Reservierung überprüfen" ist hingegen erfolgreich. Bei beiden Test geht es um die SCSI-3 permanente Reservierung. Mit dem Unterschied das bei dem ersten Test von Clusterspeicherpools die rede ist. In dem link steht Storage Spaces (ist für mich das 2k12 Datei Server Feature) und ich lese daraus das die Warnung ignoriert werden kann, weil ich keine Storage Spaces einsetze oder habe ich da jetzt einen Denkfehler?

Moin, du kannst RemoteFX auch in einem Terminal Server nutzen. Windows 8.1 Enterprise macht hier Sinn, weil dort alle RemoteFX Features nutzbar sind und zudem ist dort schon die VDA Lizenz(brauchst du für VDI Umgebung) enthalten. Grafikkarte sind zb die K1 und K2 von Nividia geeignet. Die Nividia Grid K1 für "viele Office" user. Die K2 empfiehlt sich laut Nividia wohl eher für wenige power user die mit Grafikintensiven Programmen arbeiten. Bei dir käme dann wohl eher die K1 in Frage. Du musst aber noch auf einige Dinge bei der Server Hardware achten, denn nicht alle Server unterstützen diese Grafikkarten. Hast du die Server schon stehen(wenn ja welche?) oder werden die noch besorgt? In den neueren wie zb HP Gen8/9 oder Dell geht das (auch nicht bei allen). Bei älteren Servern wird das meist gar nicht gehen oder zumindest nicht supportet sein