Blase

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

Ist das Thema so... "speziell"...?! Oder bin ich hier im falschen Forum gelandet? Würde mich wie geschrieben schlicht über ein paar Anmerkungen, Bestätigungen oder Verbesserungen freuen... Gruß Björn

Moin, ich hoffe ich bin hier im Forum an der richtigen Adresse. Ich habe das Thema Lokalisierung noch nicht ganz verstanden im Bezug auf was da geht und wann da Kosten entstehen. Ausgangslage sind zwei PCs mit deutschem Windows 7 Professional und einem deutschen Office 2010 Home & Business und der andere mit deutschem Office 2013 Home & Business. Diese PCs laufen schon einige Monate so. Die sollen beide jetzt "komplett in englisch" sein, bzw. umgestellt werden, weil die Benutzer das gerne so hätten. In der Ultimate Version von Windows 7 kann man ja die Sprachpakete einfach herunterladen und installieren (über das Windows Update) - wie sieht das mit Windows 7 Professional aus? Hier habe ich bisher die "LIPs" gefunden - jedoch nicht in englisch. Und beim Office 2013 habe ich gesehen, dass man das kaufen kann, bzw. muss, wenn man es denn haben möchte. 19.99 Euro für die englische Version. Beim Office 2010 wird gar nichts mehr angeboten... Sind diese Informationen korrekt und aktuell? Bekomme ich mein Windows 7 Professional nicht auf englisch umgestellt, ebenso wenig wie das Office 2010 und lediglich das Office 2013 wenn man 20 Euro auf den Tisch legt? Würde ich über Aufklärung freuen. Gruß Björn

Hallo Norbert, vielen Dank für die rasche Antwort. Dann noch ein zwei Detailfragen ;-) - Wenn ich mit Exchange 2013 als nötigen Zwischenschritt arbeite und dann letztlich Exchange 2016 dort installiere, wie sieht das lizenztechnisch mit dem Exchange 2013 aus? Muss der für den nötigen Zwischenschritt lizenziert werden? Oder geht das ohne Lizenz? Ich habe bisher einen Exchange immer nur mit einer passenden Lizenz installiert. - bezüglich der Übernahme Exchange 2007 in 2013 in 2016... kann die Übernahme in 2013 und dann in 2016 auf der selben Maschine passieren? Ich installiere auf einer virtuellen Maschine 2013, übernehme die Daten und mache dann dort ein Upgrade auf 2016, ja? Muss mich da allerdings komplett rein lesen... - Wenn es eine klare Empfehlung gegen einen Betrieb von DC und Exchange auf der selben Maschine gibt, weißt du eine Seite für mich zum reinlesen in diese Thematik? Alternativ - wenn du magst - kannst du mir das kurz erklären, was die Probleme sind bzw. warum die Empfehlung klar dagegen ist? Danke Dir! Gruß Björn

Guten Morgen, wir haben einen Kunden mit EINEM physikalischen Server - einem SBS2008 - welcher jetzt in Rente geschickt werden soll. Geplant ist die Übernahme/Migration der Domäne inkl. Exchange und der Übernahme des lokalen SQL Servers (2008 Std) hinter welchem ein ERP System steckt. Wir wollen das nun mit Server 2012 R2 gestalten und virtualisieren, um zukünftig auch etwas flexibler zu sein. Ich habe leider noch keine Erfahrungen mit Exchange 2016, lediglich mit Exchange 2013. Meine Fragen: - Können/dürfen der DC und Exchange auf der selben Maschine laufen? Erfahrungen/Empfehlungen? - Könnte/sollte ich gleich auf Exchange 2016 gehen? Migration vom "SBS 2008 Exchange" in den 2016 Exchange in einem Rutsch möglich? - Und eine Frage bezüglich der Virtualisierung bzw. zu den Lizenzen. Mit einer Standard 2012 R2 Lizenz kann/darf ich ja zwei virtuelle Maschinen installieren (mit der selben Lizenz). Wenn ich DC und Exchange trenne, bräuchte ich aber wahrscheinlich drei virtuelle Maschinen, weil ich ohnehin vorhatte, den SQL Server und das ERP System auf einer getrennten Maschine unter zu bringen. Wäre es lizenztechnisch dann ok, wenn ich hier einfach eine weitere Standard 2012 R2 Lizenz dazu nehme? Dürfte ich dann mit dieser noch zwei weitere (also insgesamt 4) virtuelle Maschinen auf dem selben Host installieren? - allgemeine Anmerkungen/Empfehlungen? Danke schon mal! Gruß Björn

So weit mir bekannt, läuft dort das gute alte "NT-Backup" (*.bkf). Wenn ich nachher mit ihm spreche, frage ich, ob das nicht reicht. Glaube ich aber eher weniger, weil ich dort nur an die Daten/Dateien ran komme (kann ich ein *.bkf überhaupt mit aktuellen Windows Versionen "öffnen/einsehen"?). Und spätestens beim ERP System nutzt das nichts, weil das Programm eben nicht lauffähig ist, bzw. erst sehr umständlich wieder zum Laufen gebracht werden müsste.

Hallo in die Runde, vielen Dank für die Antworten. Ich werde noch mal mit dem Insolvenzverwalter sprechen und ihn auf die möglichen Probleme aufmerksam machen. Aber wie ich letztlich "sichere/umwandle/virtualisiere/..." spielt doch keine Rolle dahingehend, als dass ich anschließend immer noch einen Windows Server 2003 habe. Muss man sich also vom Gedanken verabschieden, dieses Konstrukt "beliebig lange" lauffähig im Zugriff zu haben? Oder gibt es hier kostenpflichtige Alternativen, die "mehr" können? Mal aus purer Neugierde in die Runde gefragt - Disk2VHD - ist das offiziell seitens Microsoft "supported"? In produktiven Umgebungen? Hier würde ich mich über ein paar Meinungen freuen. Bisher installiere ich nämlich immer brav neu... Gruß Björn

Hallo, folgende Ausgangslage. Kleine Firma, welche in Konkurs gegangen ist. Dort steht ein einziger Windows Server 2003 (R2?!) Standard rum, welcher bis heute seine Dienste (DC, DNS, Storage, ERP) verrichtet. Meine Aufgabe ist es, ein wie auch immer geartetes "bootfähiges Image" im Format VHD oder VHDX des IST Zustandes des Servers zu erstellen, welches bei Bedarf dann zu einem beliebigen Zeitpunkt auf einem anderen ("beliebigen") System wieder herzustellen ist. Dies möchte der Konkursverwalter so. Meine Frage ist nun, welche (wenn möglich kostenfreie) Software nutze ich für solche Zwecke? Habe ich zumindest noch nicht gemacht. Empfehlungen? Meinungen? Gruß Björn

Ähm, habe ich was falsches gesagt?! :shock: Ich weiß lediglich nicht, wann ich die nächste Gelegenheit bekommen werde, auf das betroffene System zu schauen und ich kenne eben Dienstleister, die hier regelmäßig die Protokolle "warten", sprich sichten und anschließend löschen... @Nils - ich habe mich hier wohl schlicht unglücklich ausgedrückt. Natürlich soll das Programm des SQL Servers in den Standard Pfaden installiert werden/sein, aber das Daten- bzw. Instanzverzeichnis nicht. Dieser soll auf das D: Laufwerk. Ich könnte einfach auf Dateiebene Pfade auf D: anlegen und meine Datenbank dort hin verschieben, aber der "Standard" Datenpfad des SQL Servers ändert sich dadurch ja nicht. Der SQL Server würde in dieser Konstellation immer in seinem Standard Datenbanken anlegen und sichern wollen - und der Standard wäre ja immer C:\... Kann man diesen so einfach (!) ändern? @XP-Fan - auch wenn das ein virtueller Server ist, wird das Volume ja letztlich über die Datenträgerverwaltung des virtuellen Servers hinzugefügt - müsste also passen. Habe das grade mal an meinem Notebook getestet - hätte vom Gefühl her gesagt, dass das älter sein müsste, kann mich aber irren. Habe noch was gefunden: Eigenschaften des Datenträgers => Reiter "Hardware" => HDD auswählen und "Eigenschaften" starten => Reiter "Details" und als Eigenschaft "Datum der Erstinstallation" auswählen. Ist identisch mit dem Wert des Erstellungsdatums "System Volume Information" :D Super - danke euch! Wüsche allen Beteiligten eine ruhige Woche. MfG Björn