Blase

Guten Morgen in die Runde, ich bin grade dabei mich erstmalig intensiver mit iSCSI zu beschäftigen. Aber ich glaube, ich habe gleich am Anfang bereits eine grundsätzliche "Blockade" im Kopf, wie iSCSI überhaupt funktioniert, bzw. aufgebaut ist. Zum kurzen Hintergrund meiner Überlegungen: Weil ich ein aktuelles Serversystem (Hyper-V Host, drei VMs, DC/DNS, Exchange, ERP, alles Server 2012 R2, alle VMs lokal auf Host im RAID 10) mit Windows Boardmitteln sichern möchte - und weil die Standard Windows Server Sicherung auf eine Netzwerkfreigabe ja keine inkrementelle Sicherung hinbekommt - "dachte" ich mir so, ich könne ja iSCSI dafür nutzen, weil damit ja eine "lokale" Platte zur Verfügung steht und ich damit dann doch wieder inkrementell sichern kann. In meinem jugendlichen Leichtsinn - und ohne weitere Kenntnisse im Bereich "iSCSI" - dachte ich mir also, ich würde mein NAS System nehmen (welches ja "iSCSI" auf der Feature Liste stehen hat), es über iSCSI mit dem Host bzw. den virtuellen Windows Maschinen verbinden und darüber dann sichern.. ... Aber je mehr ich über iSCSI lese, desto weniger glaube ich, dass das so funktioniert... In so ziemlich allen "Anleitungen", die ich bisher durchstöbert habe, ist überhaupt nicht die Rede von einem NAS oder SAN System. Es geht dort immer um ein "Windows Storage", also ein Serversystem mit zB Windows Server 2012 R2 drauf, auf welchem dann die Rollen "iSCSI Target Server" + "Target Storage Provider" drauf kommen. Die Konfiguration beschäftigt sich dann mit einer LOKALEN Anlage von VHD Dateien und die Zuweisung beliebiger Server im Netzwerk, die darauf Zugriff haben. Dann soll auf den "Clients" über den "iSCSI Initiator" auf eben dieses Target zugegriffen werden. Dann habe ich in der Datenträgerverwaltung einen neuen Datenträger, den ich dann nutzen kann... Nun ja, an sich ist das schon so verständlich - und mein ursprüngliches Vorhaben damit ad acta gelegt - es bleibt aber die Frage, warum auf der Feature Liste einer terra NASBOX 5 G3 eben "iSCSI" drauf steht und was es dann in diesem Zusammenhang mit der NASBOX meint? Freue mich über jegliche Meinungen und Anmerkungen in diesem Kontext. Gruß Björn

Guten Morgen in die Runde, kleines abschließendes Feedback von mir hierzu - falls es jemanden interessiert ;) Bedingt durch das Feedback hier (vielen Dank hierfür!) habe ich es "einfach" gehalten. Ich habe schlicht die virtuellen Maschinen herunter gefahren und erst einmal so konfiguriert, dass sie weder beim Start des Hosts mit gestartet werden, noch beim Herunterfahren des Hosts ebenfalls sauber herunter gefahren werden. Dann habe ich den kompletten Ordner Hyper-V inkl. Unterordner über Nacht auf zwei verschiedene NAS Systeme kopiert - doppelt zur Sicherheit. Und ich habe - ohne zu wissen, ob nötig oder nicht - die Hyper-V Dienste des Hosts auf deaktiviert gesetzt. Heute Morgen dann habe ich direkt den Hyper-V Host herunter gefahren und die Platten getauscht - OHNE vorab das alte RAID System aus dem Controller zu entfernen. Daraufhin hat der RAID Controller beim booten - noch bevor ich zur Config des RAID Controller kommen konnte - gemeckert, dass das vorhandene RAID 10 nicht mehr in Takt sei und was ich machen möchte. Ich habe schlicht weiter booten lassen und bin dann in den Controller rein. Altes RAID gelöscht, neues aufgebaut und in Windows gebootet. Dort dann die neue Partition erstellt und die komplette Ordnerstruktur vom NAS zurück kopiert. Was NICHT ging, war der sofortige Start der virtuellen Maschinen in der Hyper-V Konsole. Ich musste schlicht die dort vorhandenen Maschinen löschen und sie neu erstellen. Dabei habe ich dann einfach auf die bestehende VHD Datei verwiesen. Klappte bei allen Maschinen problemlos. Insgesamt gab es auch anschließend keinerlei Probleme - bis auf eine einzige Ausnahme: Der virtuelle Exchange Server hatte Probleme mit seiner Netzwerkkarte. Und zwar bekam dieser Server keine Verbindung zum Netzwerk. Tatsächlich sah ich im Geräte Manager des Servers ein "Gelbes Gerät" - die virtuelle Netzwerkkarte. Text hierzu: "Es wurde Treibersoftware für das gerät gefunden aber bei der Installation ist ein Fehler aufgetreten. Dieses gerät ist nicht richtig konfiguriert code 1" Ist schlussendlich die selbe (virtuelle) Netzwerkkarte, welche auch den anderen virtuellen Maschinen zugewiesen worden ist und dort gab es keine Probleme. Unter Windows konnte ich jedenfalls die Treiber scheinbar nicht installieren. Ich hatte versucht, im Hyper-V Manager die Netzwerkkarte neu zuzuweisen - als letzter Versuch wurde sie auf dem virtuellen Computer sogar "entfernt" (also über die Hyper-V Konsole) und anschließend neu "installiert"/zugewiesen. Beim anschließenden Start der VM, kam dann unter Windows auch die "Installation der neu erkannten Geräte", inkl. erfolgreicher Treiberinstallation. Ich konnte nun endlich auf den virtuellen Netzwerkadapter zugreifen und ihm wieder fest seine IP etc zuweisen. Das hat mich ein paar Versuche/Neustarts gekostet und es hat auch stellenweise beim Neustart verhältnismäßig lange gedauert, bis ich die virtuelle Netzwerkkarte endlich im Zugriff hatte. Nun laufen alle Maschinen auf dem neu erstellten RAID 10 - toi toi toi :jau: Gruß Björn

Moin. Gegeben ist ein HP DL 380 G7, welcher als Hyper-V Host seinen Dienst tut. Er hat 8 Festplatteneinschübe - auf zweien davon läuft das Betriebssystem (Win 2008 R2 auf 2 x 150er Platten im RAID 1 und 5 (4 + Hotspare) sind 300er Platten im RAID 10. Hierauf liegen einzig die VMs. Nun wurde der Plattenplatz der VMs zu klein und musste erweitert werden. Wird sind ziemlich günstig an 7 x 600er Platten ran gekommen, welche nun (6 davon) ein neues RAID 10 bilden sollen - eine "Ersatzplatte" kommt in die Schublade. Soviel zum "Drumherum". Ich bin jetzt einfach nicht so sicher, ob die "Vorgehensweise" hier richtig ist, bzw. ob ich etwas übersehe/auslasse. 1. Die VMs herunter fahren 2. Die VHDs (die komplette Ordnerstruktur) woanders zwischenspeichern. 3. Server herunter fahren 4. Platten tauschen 5. ins Bios des RAID Controllers booten (übrigens ein Smart Array P410i) und die 6 Platten zum RAID 10 konfigurieren 6. Windows booten, neue Partition einrichten (selber "Buchstabe" wie vorab) 7. VHDs zurück kopieren, starten, fertig An sich ja, würde ich meinen, ziemlich trivial. Dennoch bin ich bezüglich Hyper-V und des RAID Controllers nicht so ganz sicher. Bezüglich Hyper-V: - Muss da noch mehr "vorbereitet" werden? Wenn ich nach dem Austausch der Festplatten erstmalig in Windows boote, gibt es unter Windows die Partition, unter welcher Hyper-V (VHds + Konfiguration) ja ursprünglich lief, noch nicht. Kann das Probleme machen? Muss ich diesbezüglich vorab Dienste deaktivieren, damit diese nicht beim ersten Start (ohne vorhandene Partition) Probleme verursachen? - Spielt es im Zuge meines Vorhabens eine Rolle, ob die einzelnen VMs so konfiguriert sind, dass sie beim Windows Start des Host Betriebssystems automatisch mit starten? - Wenn die VHDs wieder zurück in die neue Struktur kopiert worden ist (die vom Aufbau her aber der alten entspricht), kann ich diese dann einfach über die Konsole "normal" starten oder muss ich die neu einbinden? - Irgendwelche "Nacharbeiten" in diesem Kontext? Bezüglich des RAID Controllers: - Kann ich dem Controller sein bisheriges RAID 10 einfach unter dem Hintern weg "klauen"? Ich wollte ja den Server herunter fahren und direkt die alten Platten raus und die neuen Platten rein. Passt? Oder muss ich den Server neu starten, in den RAID Controller booten und dort erst das vorhandene RAID 10 auflösen/löschen? Würde mich übe ein kurzes Feedback und Anmerkungen / Meinungen freuen. Gruß Björn

Moin Franz, lustig - eben diese Powerpoint hatte ich auch gefunden. :) Hier wird - meiner Meinung nach - allerdings lediglich von Windows CALs, nicht aber von SQL USER CALs gesprochen. Oder habe ich den Punkt schlicht "überlesen"? So oder so - nicht grade viele Quellen, geschweige denn eine "normale offizielle" Quellenangabe auf irgend einer MS Seite...?! Spricht Microsoft nicht so gerne über das Thema? Die SQL Software wird einmalig bezahlt - und bei Bedarf/auf Wunsch wird auch ein Wartungsvertrag optional angeboten. Gruß Björn

Hallo Franz, ich hatte jetzt die Gelegenheit, einen Kontakt zum besagten ISV herzustellen und dort einmal nachzuhaken. Bestätigt wurde, dass die Lizenzen an das Produkt gebunden sind, mit welchem die Lizenzen ursprünglich vom ISV gekauft worden sind. Wird das ursprüngliche Produkt nicht mehr eingesetzt, verlieren die Lizenzen ihre Gültigkeit. Der ISV sprach von "allen MS Lizenzen" als Antwort auf meine Frage, in welcher ich Server und CALs und Core Versionen ansprach. Er hat explizit nicht auch von CALs gesprochen - und ich habe bisher NICHT explizit nachgefragt - aber der Formulierung nach zu urteilen würde das auch die CALs beinhalten. Du hast selber nicht 100 prozentig klar geschrieben... "diese dürfen sicherlich..." Bevor ich also die explizite Nachfrage an den ISV stelle, wollte ich gerne vorab noch einmal deine Einschätzung dazu. Ich tue mich einigermaßen schwer mit der Suche nach "channel agnostic". Habe bisher nur eine offizielle Microsoft Quelle (ein PDF) dazu gefunden, in welcher das erwähnt wird - aber im Zusammenhang mit (Windows) Server CALs und nicht im Zusammenhang mit SQL. Hättest du einen Link zu einer offiziellen MS Seite? Gruß Björn

Mahlzeit in die Runde, vielen Dank für die Meinungen - das Thema ist für mich jetzt klarer. Werde noch abschließend bei unserem ERP Lieferanten mal Fragen, wie er das Thema so sieht.. @Nils - Dass VDI und Terminal Server die Paradedisziplin bezüglich Dynamic Memory ist, ist verständlich. Aber es hängt ja doch sicherlich trotzdem mit der verwendeten (NICHT Microsoft) Software auf dem (virtuellen) Client / Terminal Server zusammen, oder? Also laut Microsoft ja bei VDI und TS - aber den Software Hersteller der relevanten Systeme sollte man trotzdem fragen...!? Gruß Björn

Moin in die Runde, mangels eigener Erfahrungen wollte ich mal horchen, wie ihr das so handhabt und bewertet. Es geht schlicht um die dynamische Zuweisung des Arbeitsspeichers unter Hyper-V. Ich persönlich weise fest zu, aber ich bin hier an einen Verfechter dynamischer Zuweisung geraten - und mangels eigener Erfahrungen kann ich nur zuhören, aber nichts dazu sagen ;-) Was ist hier "best practice"? Klar, mit einer dynamischen Zuweisung "verschwende" ich keinen fest zugewiesenen RAM, der aber vielleicht (grade) nicht genutzt wird. Andererseits, funktioniert diese "Dynamik" uneingeschränkt? Hat das negative Auswirkungen? Gilt das für virtuelle Server UND Clients? Würde mich über kurzes Feedback freuen Gruß Björn

Guten Morgen Franz, vielen Dank für dein Feedback. Die vorliegende Preisliste ist leider recht... sagen wir "übersichtlich" gehalten. Es steht schlicht, dass "das Nutzungsrecht für den SQL Server endet". Ok, wenn man sich an die Worte heftet, steht dort schon "Server", aber ein Nachsatz von wegen "CALs noch weiter nutzbar" wäre nicht schlecht. Zumal, das betrifft ja auch die Core Version - welche ja nicht extra noch mit CALs zu versorgen ist. Da gibt man also mindestens über 10k Euro aus (Standard, 2 x 2Kerne) und steht am Ende möglicherweise "nackt" da? Das will mir irgendwie nicht in den Kopf. Kostet der SQL Server bei einem NICHT ISV so viel mehr? Ich tue mich grade einigermaßen schwer, mich hier im Abkürzungsjungel zurecht zu finden... :confused: Danke auf jeden Fall für deine Erläuterungen! Gruß Björn

Hallo David, bei der Runtime macht es gleichzeitig sinn und ist obsolet zugleich. Denn warum sollte ich den SQL Server weiter nutzen, in welchem ich ohnehin nur AUSSCHLIESSLICH die Datenbanken des ISVs laufen lassen darf/kann?! Hier macht der Satz entsprechend sogar keinen Sinn, bzw. es sollte einfach selbstverständlich sein. Aber das meinte ich auch nicht. Der Satz steht ausdrücklich im Bereich "Full Use", also in den teureren NICHT Runtime Lizenzen und in der Core Lizenz. Hier finde ich das schon nicht ohne. Denn die Preise sind für mein Dafürhalten eben nicht spürbar günstiger. Wobei "mein Dafürhalten" hier möglicherweise auf dünnem Eis steht. Gibt es für "Otto Normal" Bezugsmöglichkeiten eines Standard SQL Servers 2014? Und CALs? Ich würde gerne Preise vergleichen. Wer weiß, was ich mir da zusammen gegoogelt habe... Aber ja, wenn du das hier zumindest schon mal bestätigst, dass das eher normal ist, hilfst du mir damit! Gruß Björn

Hallo in die Runde, mir ist etwas auf der Preisliste eines ISVs (Independent Software Vendor) bezüglich seiner angebotenen MS SQL Lizenzen aufgefallen. Sein Produkt basiert auch auf dem MS SQL Server und entsprechend bietet er bei Bedarf (für kleine Umgebungen würde die "Express" Variante reichen) eben solche Lizenzen an. - Als "Runtime", wo dabei steht, dass innerhalb einer solchen Lizenzierung ausschließlich Produkte eben dieses ISVs genutzt werden dürfen - und ausdrücklich keine anderen (ist etwas günstiger). Zzgl. CALs. - Dann als Einzellizenz "Full Use", wo es die Beschränkung auf ausschließlich eigenen Produkte nicht mehr gibt. Zzgl. CALs - und letztlich als Core Lizenzierung soweit so gut, nehme ich an. Was mir dabei aber ins Auge gesprungen ist, ist ein Nebensatz der besagt, dass das Nutzungsrecht für den SQL Server endet, wenn das Produkt des ISVs, für welches ursprünglich der SQL Server angeschafft worden ist, nicht mehr eingesetzt wird. Also das finde ich schon ein wenig "stark" - zumal die Preise bezüglich SQL hier nicht wirklich günstig sind. Ist sowas rechtens, geschweige denn gängig? Würde mich über ein paar Meinungen freuen. Gruß Björn

Hallo ihr beiden, @Sebastian - ich mag das Problem irgendwie noch nicht so richtig in Richtung ERP (ist übrigens die Sage Office Line) schieben. Schließlich hängt es irgendwie mir der Kennwortänderung im AD zusammen im Zusammenhang mit dem "nackten" SQL Benutzer - unabhängig vom ERP. Dennoch habe ich dort eine Anfrage gestartet - hier hält man sich allerdings bisher bedeckt. Ich könnte so erst einmal keine Unterschiede zu anderen Benutzer ausmachen. Der betroffene Benutzer ist aus dem Team Vertrieb - und ist, wie auch andere Benutzer, dann sowohl im Vertriebsteam im AD und auch im Bereich ERP, was dann beides entsprechende Berechtigungen mit sich bringt. Aber das betrifft wie gesagt auch ein paar andere Benutzer, die das Problem nicht haben. Klar könnte ich ihm auch einen komplett neuen AD Benutzer erstellen - davon wollte ich erst einmal absehen. NACHTRAG: Und der 2003er Server ist nur noch so lange im Einsatz, bis ein weiterer 2012er DC seinen Dienst tut. Ich wollte lieber so, als ohne Replikation... @Nils - das ist eine reine SQL Authentifizierung, also keine Windows Logins. Bei letzterem hätte ich mir das ja noch irgendwie zusammen reimen können. Ist aber tatsächlich nicht der Fall. Wo ist also die "Schnittstelle"? Ich habe einen AD Benutzer, der für eine ERP Software auf einem 0815 MSSQL Server einen (SQL) Benutzer hat. Die beiden Benutzer haben ja so erst einmal nichts miteinander zu tun. Scheinbar aber doch. Wo bzw an welchen Stellen innerhalb des SQL Servers könnte das sein? Gruß Björn

Moin, Umgebung: AD mit Domänenfunktionsebene: Server 2003 - zwei DCs - ein 2003 Standard und ein 2008 R2 Standard - letzterer beheimatet alle FSMOs. Ein SQL Server 2008 R2 Standard auf einem Memberserver der Domäne mit Windows Server 2008 R2 Standard. Ein Benutzer hat ein merkwürdiges Verhalten. Wir haben seitens unseres ADs vorgeschriebene Kennwortänderungen der AD Benutzer alle 4 Wochen. Ändert dieser eine Benutzer sein Kennwort im AD, verschwindet sein SQL Benutzer und er kann sich nicht mehr an unsere ERP Software anmelden. D.h. der Benutzer taucht im Management Studio unter Sicherheit / Anmeldungen nicht mehr auf - er ist nicht mehr da, nach der Kennwort Änderung im AD. Unsere ERP Software "bemerkt" auf administrativer Ebene dann, dass es SQL Benutzer innerhalb ihrer Datenbank gibt, die noch nicht im SQL Server registriert sind - eben dieser SQL Benutzer. Man kann ihn dann im Kontext wieder herstellen - mit leerem Kennwort. Dann ist er unter Sicherheit / Anmeldungen wieder da und der Benutzer kann sich im ERP wieder (mit leerem Kennwort) anmelden und sich ein Kennwort seiner Wahl vergeben. Bis er in 4 Wochen seinen AD Benutzer wieder ein neues Kennwort verpasst... Das Betrifft wie gesagt nur einen einzigen AD bzw. SQL Benutzer. Bei allen anderen AD Benutzern tritt dies Verhalten nicht auf. Eine Idee, in welche Richtung ich hier überhaupt schauen soll? Bin ziemlich ratlos... Gruß Björn

Wenn ich die Sicherung vom Host aus ausführe, wird dann der Exchange auch "anständig" mit gesichert? Also Protokoll weg geschrieben und so? War mir nicht bewusst, dass die Sicherung auch zentralisiert vom Host aus gemacht werden kann. Das wäre natürlich einfacher. Eine Frage noch hierzu - im Wiederherstellungsfall, wie "einfach" komme ich dann an die Sachen dran, die in den VMs liegen? An ein einzelnes Postfach käme ich dann wiederum aber mit weiterer Software dran. Zugegeben - dann könnte man das Geld auch gleich in eine etwas "umfangreichere" Sicherungssoftware stecken... Ich bin immer aufgeschlossen für neue (mir unbekannte) Software. Das von dir genannte Werkzeug kostet 325 Euro pro Jahr und Host (bei 5 VMs), ja?! Sicherlich gerechtfertigter Preis, wenn Sicherung und Wiederherstellung "einfach" von der Hand gehen. Muss mir den genauen Funktionsumfang mal anschauen... Danke Dir für die Empfehlung.

Das wäre mir neu - zumal es nicht erklärt, warum auf dem ERP Server das selbe Problem auftritt...

Folgende Ausgangslage: 1 x Hyper-V Host 3 x virtuelle Maschinen => DC / Exchange / ERP ERP und Exchange sind natürlich "normale" Memberserver der Domäne - alles Server 2012 R2 mit aktuellstem Updatestand. Auf dem DC ist eine weitere Partition zugewiesen, auf welcher die Sicherung aller Gastsysteme (also die drei virtuellen Maschinen) zusammen laufen soll, bevor Sie letztlich vom Server "gesammelt" weiter verarbeitet und zentralisiert abgelegt werden. Für den Moment ist das eine Zwischenlösung, bis ein NAS System vorhanden ist, auf welchem dann direkt zentral gesichert wird. Auf dem DC, Exchange und ERP soll also über die integrierte Standard Windows Sicherung auf die Freigabe \\SRVDC\Serversicherung\ geschrieben werden - jeweils noch in ein eigenes Unterverzeichnis (".\DC", ".\Exchange" und ".\ERP"). Die Joberstellung und auch die tatsächliche Sicherung auf dem DC selbst (der auch die UNC Notation nutzt) funktioniert. Beim Exchange und ERP leider nicht. Wenn ich in der jeweiligen Windows Sicherung den Sicherungspfad eingebe, kommt am Ende eine Authentifizierung - diese wurde auf allen drei Maschinen einheitlich mit dem Domänen Administrator vollzogen. Bis hier hin noch keine Probleme (er würde ja zB bei einem falschen Kennwort hier schon "meckern"). Wenn ich den Sicherungsjob nun aber speichern möchte, bekomme ich nach kurzer Zeit eine schlichte Meldung von wegen "Benutzer oder Kennwort falsch". Ich stehe wohl auf dem Schlauch bzw beachte offensichtlich etwas Wesentliches nicht. Warum kann der DC das einrichten, die beiden anderen Maschinen aber nicht? In der Ereignisanzeige habe ich nichts weiter nach der fehlgeschlagenen Joberstellung finden können. Kann mich mal bitte jemand in die richtige Richtung schubsen? Gruß Björn

Hallo Forum, laut dieser Anleitung: https://technet.microsoft.com/de-de/library/9aa53be9-0497-49fa-9ff6-09b72cb69444(v=ws.10)#BKMK_RmvCA "sollte" der Rechnername des Zielservers der neuen CA identisch mit dem Namen des Quellservers der alten CA sein. Darüber hinaus muss die alte CA vom Quellserver sauber entfernt werden, BEVOR die CA auf dem neuen Server eingerichtet wird... Ist das wirklich "best practice"?! Denn es heißt ja im Klartext, dass man die alte CA sichert, die CA dann komplett vom System runter nimmt und das System letztlich aus der Domäne entfernt. Dann bringt man den neuen Server mit identischen Namen in die Domäne, installiert die CA und sichert zurück. Klar, kann man so machen, aber das bedeutet ja auch, dass man "eine Zeit lang" komplett OHNE aktiver CA in der Domäne unterwegs ist. Hat das nicht Folgen für "den laufenden Betrieb"?! Mal ganz davon ab, dass es im Wiederherstellungsprozess ja auch Probleme geben könnte und man möglicherweise gezwungen wird, zurück auf die alte CA zu gehen... Ich habe hier neben dieser "Anleitung" so einige andere gelesen und praktisch keine davon geht auf diesen Umstand ein. Mal salopp formuliert - sind die jetzt alle b***d - oder ist das nur "übertriebene" Vorsicht seitens des TechNet Artikels? In den "sonstigen" Anleitung wird i.d.R. "einfach" auf einem neuen Server die CA installiert und dann das vorherige Backup zurück gespielt. In der Registry (im relevanten zuvor gesicherten Eintrag) gibt es einen Punkt, wo der FQDN des alten Quellservers drin steht - dieser wird, je nach Anleitung, dann mal händisch überschrieben... Wie handhabt ihr das? Oder gibt es gar Fälle (im "kleinen" KMU Bereich), wo ihr euch entscheidet, die CA einfach neu zu machen? Würde mich über eure Meinungen hierzu freuen. Gruß Björn

Guten Morgen allerseits, geplant ist die Migration eines SBS 2008 mit allem "drum und dran" hin auf ein aktuelles System. Ich hätte in diesem Zusammenhang ein paar Fragen: 1. Der SBS hat ja eine ganze Reihe von Gruppenrichtlinienobjekten im Standard, welche bei einer AD Migration ja erst einmal übernommen werden. Tatsächlich gibt es, neben den beiden "Default" Richtlinien nur eine einzige "Kunden" Richtlinie - aber eben gleich 10 "Standard SBS" Richtlinien. Natürlich schaue ich mir die auch alle mal an, aber wäre trotzdem an eurer Meinung interessiert. "Kann man übernehmen"? "Muss man nicht" bzw. "kann man anschließend (wenn es den SBS nicht mehr gibt) löschen?" 2. Die zweite Frage beschäftigt sich mit der Herausnahme des SBS aus dem Netz. Ich nehme an, ich sollte ihn wie jeden anderen DC, der vom Netz genommen werden soll, auch herabstufen und aus dem AD nehmen. Aber muss ich noch "mehr" machen? "SBS" ist nicht so mein Thema. Im Hinblick auf Exchange? Der läuft dann auf einen anderen 2012 R2 Server und die Daten sind übernommen. Muss ich dann im Hinblick auf Exchange noch "Rest-/Aufräumarbeiten" auf dem SBS oder anschließend im AD durchführen? Alte Einträge mit ADSI Edit entfernen? 3. Sonstige Anmerkungen bezüglich "Herausnahme des SBS aus dem Netzwerk"? Gruß Björn

Hey Jungs, vielen Dank für die vielen Antworten in dieser kurzen Zeit. @Doso - danke dir für deine Ausführungen! :thumb1: @Nobbyaushb - schläfst du auch mal?! ;-) *räusper* auch wenn ich weiß, dass ich dafür jetzt "Schelte" bekomme... die Abholung mittels Popconnector ist geplant... Ehrlicher Weise aber eher mangels "know how", wie das anders zu lösen ist. Ich "weiß", dass es auch eine Kommunikation "direkt" mittels "MX Record" providerseitig geht - und das das hier im Forum GANZ KLAR die bevorzugte Variante ist... aber so richtig befasst habe ich mich mit dieser Methode bisher nicht. Ein "Vorteil", den ich aber beim Pop3 Connector sehe, ist (gerne Feedback zu diesem Gedankengan!), dass dann provider-seitig "kostenlos" bereits auf SPAM und Viren gescannt wird. Wenn ich dort die Postfächer nicht direkt einrichte, muss ich das ja kundenseitig abfangen, was nicht ganz unerhebliche Kosten und Aufwände nach sich zieht, oder? Archivierung im Zusammenhang mit Exchange habe ich zwar schon öfters gehört, aber dass das jetzt Pflicht ist, ist mir neu. In dem Projekt wird das dann höchsten nachgeschoben bzw. Archivierung ist grade ein mittelfristiger Punkt im Bereich ERP - könnte hier dann also integriert werden. Der Nutzen eines zusätzlichen DCs ist klar - und bei mehrerer vorhandener Hardware von mir auch bevorzugt - aber im konkreten Fall zumindest vorerst nicht geplant. Seit dem R2 wäre das doch kein Thema mehr, einen Hyper-V Host in der Domäne zu haben, bei der der DC aber selbst nur ein Gastsystem des Hosts ist, oder? Ich könnte höchstens den "ausgemusterten" SBS2008 nutzen - bzw dann eben nicht ausmustern und das AD dort weiter laufen lassen. Dann wiederum können die FSMOs aber nicht auf dem 2012R2 DC liegen... auch nicht so dolle... @testperson - die CA (die meinte ich tatsächlich ;) ) ist/war in der Tat "nur" für das interne Exchange Zertifikat geplant. Und auch wenn ich weiß, dass dann beim OWA Zugriff Zertifikatsfehler kommen, wenn man es denn überhaupt nutzt, so habe ich abseits dieser Meldung bisher keine schlechten Erfahrungen mit einem selbst ausgestelltem (Exchange) Zertifikat gemacht. Spricht denn - abseits der OWA Meldung - etwas signifikantes GEGEN ein selbst ausgestelltes Zertifikat? Dass man eine CA nicht auf einem 2012 R2 DC installieren darf/kann, ist mir allerdings neu :jau: Oh man, ich mache solche Sachen wohl einfach zu selten :rolleyes: Gruß Björn

Guten Abend allerseits, ich werde einen SBS 2008 Server (der einzige Server im Unternehmen auf "Blech") ablösen und dort dann eine neues Blech hinstellen und darauf einige virtuelle (Hyper-V) Server (DC/CA, Exchange, ERP - alles Server 2012 R2) betreiben. Einer davon wird dann der neue Exchange Server - vorerst in der Version 2013 (von 2007 zu 2016 in einem Schritt geht ja nicht). Letztlich wird alles migriert, also sowohl das AD als auch Exchange als auch den Rest. Speziell zur Migration Exchange habe ich einige - für euch sicherlich ziemlich einfache - Fragen: - Vorab gleich eine allgemeine aber für mich ziemlich "wichtige" Frage: Muss ich - im Zusammenhang mit der Exchange Migration - hier irgendwie den SBS "beachten"? Oder anders ausgedrückt - ist der Exchange 2007 auf einem SBS anders zu behandeln (=> verhält er sich anders), als wenn er auf einem "Standard" Server laufen würde?! Ich habe eher nichts dazu gefunden, also wäre die Antwort wahrscheinlich "nein", aber ich frage lieber vorab. - Der 2007er Exchange muss ja für die Migration mindestens die Version SP3 + RU10 haben - ich nehme dann aber einfach das aktuellste RU16, oder? - "Downtime" ja/nein?! Oder anders gefragt - kann (theoretisch und praktisch) während der Aktualisierung des alten Exchange auf SP3 RU16 an den Clients weiter in Outlook gearbeitet werden? Die schalten einfach in den offline Modus, oder?! Aber praktisch werden keine Mails ankommen oder rausgehen, während dieser Zeit, oder? - Gleiche Frage, aber im Hinblick auf die Migration der Postfächer usw. Die Clients könnten hier einfach in Outlook "weiter" machen (eben offline), aber wirklich senden/empfangen geht erst wieder, WENN das Postfach migriert ist und die Konnektivität serverseitig auf dem neuen Exchange wieder hergestellt ist, ja?! - Muss das (alte) Active Directory irgendwie vorbereitet werden? Also mir ist klar, dass das im Zusammenhang mit der AD Migration auf einen 2012er R2 DC ohnehin passieren muss (eben FÜR das AD), aber auch im Zusammenhang mit dem Exchange? - Ich sehe grade, dass die Installationsdateien des "CU12" für Exchange 2013 von der Dateigröße her sogar noch ein wenig größer ist, als Exchange SP1 DE (ca. 1,6 GByte). Bietet MS die CUs wie auch die SPs nicht gesondert an, sondern schnürt immer gleich eine komplette Installation, mit welcher Exchange frisch installiert werden kann? Dann kann ich ja mit dieser erstmalig gleich Exchange 2013 installieren, ja? - Der alte Server soll ja nach der (kompletten) Migration natürlich ausgemustert werden. Ich bin nur nicht sicher, wie das beim SBS aussieht? DCPROMO mit der Herausnahme/Herabstufung des AD? Exchange Deinstallation auf dem SBS? Über eine kurze Auskunft, "ob" (davon gehe ich mal aus, dass das nötig ist) und vor allem "wie" ich den SBS "sauber" entferne, würde ich mich freuen. Von meiner Seite aus wären das erst einmal die Fragen :) Über Anregungen und Vorschläge auch abseits dieser Fragen freue ich mich! Gruß Björn

So dämlich ich das auch finde, aber ich habe jetzt den zugewiesenen RAM etwas reduziert. Damit ist die BIN Datei tatsächlich nicht so groß und ich habe erst einmal wieder "Luft".... Hier muss also nicht mitttel- sondern kurzfristig was mit den HDDs passieren...

Hallo Nobby, die VMs sind so konfiguriert, dass sie beim Herunterfahren des Hosts auch herunterfahren ("Gastbetriebssystem herunterfahren"). Warum sprichst du in diesem Kontext diese Einstellung an? Hängt das zusammen? Also wenn es NICHT so wäre, hätte das Auswirkungen auf besagte BIN Files? Da denkt man, man tut seinem Host was gutes und dann das... ;-) Wie ich die Kuh vom Eis bekomme weiß ich jetzt wohl immer noch nicht.... Kann man die BIN Files auch auf einer anderen Maschine bzw. auf einem NAS speichern? Sicherlich alles anders als "best practice", selbst wenn es ginge - nehme ich an...?! Aktuelles Dateisystem ist im Rack des Servers drin - RAID1 für C:\ und RAID10 für E: - hier liegt nichts außer die VHDs und eben die BIN Files...

Es ist pro VM auch nur ein BIN File, aber es sind halt 5 Maschinen. Sie liegen auch nicht auf dem Systemlaufwerk (RAID1), aber das eigens hierfür erstellte Laufwerk (RAID 10) ist quasi voll und das ging grade ziemlich "schnell", seit dem ich das letzte Mal geschaut habe... ... aber wenn es ein Abbild des Arbeitsspeichers ist... der wurde kürzlich erweitert - also physikalisch - und den Maschinen entsprechend mehr zugewiesen - kann das damit zusammen hängen? Also kann ich den Pfad des "Config" Ordners nur global für alle Maschinen erstellen und nicht pro Maschine... das macht es grade nicht leichter *grummel*

Hallo ChrisRa, danke für die Aufklärung! Kann/darf das woanders liegen? Habe in meiner Hyper-V Konsole diesbezüglich auf die Schnelle keinen Eintrag gefunden? Wenn ich das schlicht umziehen kann/darf, würde mir das für den Moment etwas "Luft" verschaffen...

Moin, Meldung hierzu: Im System wurden keine Schattenkopien gefunden... Noch Ideen? Was machen diese BIN Dateien genau? Gehören ja zu den VMs - wachsen die auch stetig mit? Kann man das begrenzen? Können die auch woanders liegen?

Moin, Wir haben einen Server 2008R2 Enterprise welcher mit der Hyper-V Rolle ausgestattet ist. Auf ihm laufen ein paar VMs und leider wird der Festplattenplat des Hostsystems knapp. Besonders ins Auge fallen unter ..\Hyper-V\config\Virtual Maschines\ diverse Ordner, in welchen GB-große BIN Dateien drin sind (Dateinamen und Ordner sind Hexadezimale Zeichenketten). Die Dateien verschwinden, wenn die virtuellen Maschinen heruntergefahren sind - macht ca. 50 GB Plattenplatz aus. Was hat es mit diesen Dateien auf sich? Kann man die löschen, verschieben, verkleinern? Snapshots gibt es nicht auf dem System... Mittelfristig ist klar, dass wir auf dem Hostsystem größere Platten brauchen - aber für den Moment würde ich gerne erst einmal Platz "schaffen". Vielen Dank für Tipps! Gruß Björn