Weingeist

Ich schalte IPv6 immer ab, komplett. Wichtig ist hierbei ausschliesslich, dass die Prefixpolicy auf die IPv4 Priorisierung gewechselt wird damit z.B. Loopback auch IPv4 verwendet. 1. Prefix Policy anpassen netsh int ipv6 set prefixpolicy ::ffff:0:0/96 60 4 netsh int ipv6 set prefixpolicy ::/96 55 3 netsh int ipv6 set prefixpolicy ::1/128 50 0 netsh int ipv6 set prefixpolicy ::/0 40 1 netsh int ipv6 set prefixpolicy 2002::/16 30 2 netsh int ipv6 set prefixpolicy 2001::/32 5 5 netsh int ipv6 set prefixpolicy fc00::/7 3 13 netsh int ipv6 set prefixpolicy 3ffe::/16 1 12 netsh int ipv6 set prefixpolicy fec0::/10 1 11 2. IPv6 Protokolle von Adaptern entfernen Geht manuell oder via nvspbind (Google) oder sehr mühsam per Registry-Walker 3. IPv6, IP-Hilfsdienst, Teredo, Isatap abdrehen REM IPv6 deaktivieren inklusive tunnel REM ----------------------------------- netsh interface ipv6 6to4 set state state=disabled undoonstop=disabled netsh interface ipv6 isatap set state state=disabled netsh interface teredo set state disabled REM IPv6 komplett ausschalten reg add "hklm\System\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 255 /f REM IPv6 Service deaktivieren reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f reg ADD "HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\TCPIP6" /v Start /t REG_DWORD /d 00000004 /f REM Evtl. schon mit obigem weiss ich jetzt grad nimmer auswendig =) Powershell Set-Service 'iphlpsvc' -startuptype "disabled" Wer mag kann auch noch die Firewall-regeln für IPv6 deaktivieren oder sogar explizite Block-Regeln erstellen. Dann Reboot. Ob nun sinnvoll oder nicht muss jeder für sich entscheiden. Ich mache das schon ewig so und habe keinerlei Probleme damit, im Gegenteil. Habe einfach keinen Bock zwei Firewallregeln für ein Problem zu erstellen sowie weltweit eindeutige Adressen in die Welt hinaus zu posaunen (etwas überspitzt) und auch noch mehrere Adresse pro Adapter zu haben. Einzige Vorraussetzung ist, dass Punkt 1 auch wirklich gemacht wird, dann ist auch das komplette abdrehen bzw. die Verhinderung durch Priorisierung kein Thema. Packt man das ganze in nen Script mit Flags, kann man es auch auf Knopfdruck rückgängig machen wenn der Support rumnörgelt.

Hatte das schon öfter auf nem SBS 2008. Ursachen gibts da einige. Die häufigste die ich sah waren Fehler mit den Journaling. Dazu müsste es aber eigentlich auch Logs geben. Wenn dem so ist, ist das mitunter ziemlich lästig weil man es nicht so richtig reparieren kann auf einem DC und zwar weil die Replikation davon abhängt. Sprich löscht man den Kram und lässt ihn neu erstellen, hast Du mächtig Ärger mit den anderen DC's. Mögliche Ursachen: - Harte Shutdowns z.B. durch Stromausfälle - Manipulation von Last-Access Bit der Files - Bei VM's aber auch Time-Out von Festplatten-Writes (sollte erhöht werden bei 2008 auf ca. 200 --> Registry) Insofern kann man eigentlich nur sagen, dass man solche DC's möglichst aus dem Dienst stellen sollte. Vorher unbedingt alle GPO's sichern! Möglich, dass die auf den anderen DC's nicht (sauber) repliziert wurden, vom Client aber immer vom SBS gezogen wurde. Mein Vorgehen wäre SBS DC Herunterstufen, SBS-Relevante Tasks und Dienste abdrehen und nach und nach alles deinstallieren was migriert wurde. Da Exchange anwesend ist, wäre es sinnvoll diesen vorher herunterzufahren damit der AD-Stand exakt der selbe ist vor und nach den Mutationen und allfälligen Recovery des SBS als DC. Ich persönlich fahre jeweils alle DC's herunter und ziehe nen Cold-Clone des SBS sowie der DC's die sonst noch rumschwirren + Exchange, dann kann ich zurück zum Start ohne Risiko eines AD-Rollbacks. Oder falls nicht möglich, alle zweit DC's vor den Manipulationen herunterstufen, dann nen Cold-Clone vom SBS damit man zum sauberen AD-Stand zurück kommt und keine anderen DC's rumschwirren können bei nem Recovery. In deinem Fall wo der SBS nen Knacks hat, würde ich aber eher ersten Weg wählen. Zum Schluss soll noch gesagt sein: Um das sinnvollste Vorgehen einigermassen exakt zu bestimmen, müssen wirklich alle Fakten auf den Tisch. Also was wollen die Maschinen vom SBS haben, sind das nur Freigaben oder auch sonstigen Kram. Können die installer-Pakete auch sonst realisiert werden usw. Warum nicht Chkdsk: Weil das eigentlich nie repariert sondern höchstens verschlimmbessert. Wenn dann nur prüfen ohne jegliche Reparatutur, dann sind auch Erfolge mit Recovery Tools wahrscheinlicher.

- DHCP auf Fileserver hätte ich jetzt keine wirklichen Bedenken. - Printserver auf Fileserver habe ich ein zwiespältiges Verhälgnis. Solange die Treiber top sind, ist es schon ok. Wenn man Home-Office Drucker integrieren muss, dann hört der Spass unter Umständen auf. - WSUS und Software-Management würde ich nicht auf den Filer packen, die Leute werden es Dir danken wenn es da mal ein Problem gibt. Da ist ja ne Menge Zusatzsoftware wie SQL-Server, ReportViewer etc. mit installiert. Sprich, lass alles wies ist. Kostet im Endeffekt mit grosser Wahrscheinlichkeit weniger oder ist zumindest auch weniger nervig (kann man nicht mit Geld aufwiegen :D). Immer dran denken, wenn 20 Leute nix arbeiten weil Du zig mal die VM neustarten willst, hast die Kosten für eine Zusatzlizenz sehr sehr schnell drin. Oder Du musst alles am Week-End machen, auch nicht so prickelnd. ;)

Unschöne Sache, hier liegt der grosse Vorteil von DFS. Da hast den Mist erst wenn Du eine Domäne umbenennen musst oder das Ordner-Design mies war. Wobei man für letzteres nen unsichtbaren Ordner in DFS übrig lassen kann. ;) Alias-Namen sind zudem recht problematisch in Verbindung mit Freigaben. Zumindest war das noch anno Server 2003 oder so noch der Fall. Seither habe ich das tunlichst vermieden. =) In meine Unterlagen habe ich damals nen Workaround vermerkt: Regedit: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parameters neuen Key mit DisableStrictNameChecking auf 1 dann noch nen SPN erstellen: setspn -a host/aliasname targetserver Artikel bei ms war: Q281308 Ich würde die Übung sein lassen und nur im Notfall nutzen. Lieber wie vorgeschlagen Temp-DC hernehmen und alles nach und nach auf DFS umstellen. Ersparst Dir viel Ärger. Ich habs einmal gemacht und nie wieder. Holt dich immer wieder mal ein. Beim SBS war und ist das eine recht mühsame Angelegenheit bei Standardprodukten ist das kein Akt. ;)

Ne, muss ned sein bei Block-Zugriff mit Random IO wenn der Controller ohne BBU - richtigerweise - auf das Write-Commit der Platte wartet. Da erreichst dann locker unterirdische Übertragungsraten. Rechnung ist auch schnell gemacht: ca. 55 x 4kb = 220 Kb/s x Anzahl Platten = Schreibleistung bei 7.5k (ok manche machen auch etwas mehr) oder 200 x 4kb = 1MB/s x Anzahl Platten bei 15k ;) Für den TO (die anderen wissens ja bestimmt): Deshalb ist es auch so wichtig bei RAID-Betrieb mit Magnetplatten einen Hardware-Controller mit möglichst viel Cache und BBU zu verwenden. Da werden die Commits geschickt wenn die Daten im Cache liegen und durch die BBU gepuffert werden. Bei Software RAID muss die Platte eben dementsprechend schnell sein und über regelmässige Zugriffszeiten verfügen. Bei Magnet ist das gegeben, wenn auch auf tiefem Niveau. Bei SSD's nur bei den sehr teuren Enterprise-Modellen. Je mehr platten da mit von der Party sind, desto eher geht die Performance in den Keller weil die Latenz von irgend einer betroffenen Platte immer grad bescheiden ist. Magnetplatten bekommen nur Beine wenn man ned aufs Commit der Platte wartet, dann ist ein Stromausfall unter Umständen aber ziemlich fatal.

Och, die gibts bestimmt, wird sich wohl mittlerweile auf VM's in Hyper-V beschränken. Da ist die Hardware immer gleich. *hust*

Wenn solch Granulare Berechtigungen für Unterordner in Frage kommen würde ich die komplette Berechtigungskette ganz dringend per Wartungscript lösen welches die Berechtigungen explizt auf Excel-Files oder bestimmte Ordner setzt. Ansonsten fliegt Dir der Kram früher oder später um die Ohren und Du hast kein Plan mehr was alles zu setzen ist. Also wenn z.B. Unterodner andere Rechte haben. ;) Je nach der gewünschten Strukturtiefe kann man auch DFS dafür hernehmen. Einen in DFS erstellte Struktur kann durch die User nicht gelöschten werden. Somit kann man eine z.B. eher flache Ordnerstruktur in eine leicht verschachtelte verwandeln (z.B. interessant wenn gewisse Files auf schnelleren oder langsameren Plattenverbünden liegen sollen als der restliche Kram der dazugehört. Da aber für jedes effekte Ordnerziel eine Freigabe benötigt wird, geht man vorteilhafterweise auch etwas sparsam damit um. So ein Schuss ins Blaue, evtl. gibt es für den Inhaber der Datei dennoch Rechte zum löschen obwohl der User diese per Gruppenberechtigung nicht hat? Dann könntest z.B. per Script durch alle Excelfiles walken und die Inhaber auf die die Bearbeitungsgruppe setzen. Nicht schön, könnte aber eventuell funktionieren. Zu Access: Die Löschrechte brauchts vor allem für die kleine ldb Datei die automatisch erstellt wird sowie zum komprimieren oder decompilieren. Daher auch gleich auf den Ordner. Gibt ganz schönen Ärger ohne. Auf der Backend kann man tricksen, auf der Frontend sollte mans lassen.

Lustig ist ja, es funktioniert ned mal immer mit en-us. Dann zum Beispiel wenn Cookies deaktiviert sind. Wird dann seit neuestem immer Deutsch angezeigt. Auch geil: Javascript wird seit einigen monaten für die KB-Artikel benötigt und für manche Artikel ein MS-Login. Zu Frage: Viel Fantasie brauchts da ned oder? Mit den Vorschau-Updates beerbst Du hochoffiziell das ehemalige Update-Auf-Herz-und-Nieren-Prüf-Team das aus Kostengründen abgeschafft wurde. Du wirst als Dankeschön fürs Testen mit attraktiven Preisen sowie excellenten Lizenz- und Datenschutzbedingungen bei neuen OS belohnt. :jau:

Ne ne, die machen das mit Sicherheit bewusst. Sicher nicht bewusst falsch aber bewusst das neue System mit aller Gewalt durchboxen. Koste es was es wolle. Alle OS von MS auf dieser Welt sollen identisch sein und den gleichen Patchlevel aufweisen. Das Ganze soll automatisch ablaufen ohne dass der User etwas machen muss oder sogar kann. Bis es soweit ist, gibts Kollateral-Schaden.

Updatezwang seitens MS durch diese Klauseln hineinzuinterpretieren ist sicher verfehlt. Und zwar alleine schon deswegen, weil es mit schlichten Einstellung wie z.B. nem Registry-Flag oder ner Firewall-Richtlinie möglich ist, den Kram per Bordmittel abzudrehen. MS versucht sich hier vor allem gegenüber dem Staat irgendwie abzusichern und nicht gegenüber dem Kunden. Das aber von Staateswegen Bestrebungen im Gange sind Richtlinien für eine sogrfältige Nutzung von IT-Komponenten herauszugeben bzw. teilweise schon Vorhandne sind, ist im Zuge der vermehrten Cyber-Atacken sonnenklar und im Grundsatz auch richtig. Man handelt grobfahrlässig wenn Computer am Netz hängen und bewusst nie aktualisiert werden. Das eigentliche Ziel wird aber insofern eh komplett verfehlt werden, weil die Probleme der Zukunft kaum gekaperte Desktop-Rechner sein werden sondern die Millionen an billigen IoT-Devices die bewusst oder unbewusst über entsprechende Sicherheitslücken verfügen, damit sie gekapert werden können und garantiert nie aktualisiert werden seitens der Hersteller. Da der Kram aus Fernost kommt, wird da auch niemand belangt werden können. Schlicht weil entsprechende Verträge fehlen und nie Zutande kommen werden.

Wenn Du deine Firewall auf Auto-Block-Out stellst (dabei halt alles konfigurieren musst) kannst Windows Update auf den Client die Kommunikationsfreudigkeit auf das local-Subnet beschränken. Dann noch den Ordner Sofwaredistri killen und schauen ob er sich mit dem WSUS verbindet und Updates holt. Würde ich bei aktuellen Windows sowieso empfehlen. (Dazu die unsichtbaren Freigaben beachten) MS macht in letzter Zeit in diese Richtung kaum etwas unbewusst. Tippe da eher auf bewusste Testläufe für die Zeit nach WSUS. In Zukunft wird wohl das Ziel sein, dass sich einmalig ein Client im lokalen Netz die Updates zieht und die anderen sich dann über diesen Versorgen sollen.

Die zusätzlichen kosten für nen Mini-Server für den DC mit Files wird mit grosser Sicherheit mit den ersten Problemen bezahlt sein --> Stichwort Wartung =) Keine 6 Jahre alt: Nun, 6 Jahre ist nicht wenig für ne Platte die 24h läuft. Vor allem wenn es Desktop-Produkte sind. Nur fallen jene erfahrungsgemäss auch ned so schnell aus die schon Jahre störungsfrei liefen.

Meines Wissens steht nirgendwo, dass er die Terminal-Server Rolle tatsächlich installieren muss. Es steht ja immer schön dabei: Oder ähnliche Technologien. Damit ist jede Art von Fernzugriff gemeint. Ob nun von MS oder einem anderen Anbieter wie Citrix. ;) Er braucht also lediglich die zwei RDP-Lizenzen. Wenn ihm 2 Zugängen reichen ist doch gut. Ansonsten macht eben Windows bei mehr als zwei dicht und will die TS-Rolle sehen. Die DC Rolle würde ich dennoch installieren. Kost ja nix. Macht vieles einfacher. Wenn Du in einzeln betreibst auch egal ob Du image oder normal-Sicherungen machst. Nachteile gibt es eigentlich keine. Hast Namensauflösung, zentrale Kennwörter usw. Ob Du die nun auf Deinem Zentralen Server arbeiten lässt oder wenn da noch der DC drauf ist kommt dann aufs gleiche raus. Man machts eigentlich ned aber wenn man eh nen single-Server-Prinzip betreibt kann mana auch mal pragmatisch bleiben. Wenn etwas mehr Geld vorhanden ist, würde ich den DC/Essentials mit Files einfach auf einen kleinen Mini-Server mit RAID10 und ECC RAM packen. Rest mit Anwendungen, Printer-Driver, Datenbanken etc. auf einen zweiten. Dann ist das grösste "Gefahrenpotential" in Sachen Sicherheit und auch Anwendungsstabilität weg von den Files und Kennwörter. Files deshalb weil Recovery eben länger dauert als ein paar DB's in ner Kleinumgebung. Die Hürde für nen Rollback ist dann tiefer wenn Druckertreiber spinnen, DBs korrupt sind etc. Den "Anwendungs-Server" kannst dann auf den DC sichern und umgekehrt.

Das kann gut sein. Habe ich auch nix dagegen bei der halb-GUI Mgmt. Aber eine "normale" Server GUI, also die schlanke Variante ist doch nicht nutzlos?!? Bin 100% sicher das waren an die 90% aller Nicht-Grossunternehmensinstallationen von 2008 bis 2012er Version. Viele Fremd-Software braucht ja die GUI nur schon für eine sinnvolle Verwaltung. Wenn was nutzlos ist, dann Desktop Experience. - normale schlanke Server GUI wie in 2012 in den Standard-Installations-Optionen - Desktop-Experience zur Nachinstallation mit Media-Player und dem ganzen Schwachsinn für die dies brauchen oder für den TS - Aktuell ist das die neue Standard GUI von Server 2016 Die 2016er GUI ist es nicht wert als Server genannt zu werden wenn der ganze oder das meiste des Desktop-Schrotts drauf ist. Hat noch wer Zugriff auf die früheren Technical Previews?

Hallo Leute, Ist das wirklich so, hat die MS minimalen GUI's komplett entfernt und jetzt gibts entweder nur noch die Pest mit Desktop-OS GUI inklusive Datenkrake, Cortana (wenn auch minimal - wird dann wohl mit Updates ausgebaut, gibt ja nur noch Rollups) sowie Media-Player oder eben Core mit gar nix? Ein Business, ja sogar Server-Produkt derart zu verunstalten. Irgendwie "speziell" Eine schlanke Server GUI in mehreren Stufen wie z.B. unter Server 2012R2 mit zusätzlich separatem Desktop-Experience scheint jedenfalls Geschichte zu sein. In früheren Technical Previews war das definitiv noch möglich. Es ist wohl wirklich Tatsache, MS betreibt nur noch Produkt-Entwicklung am (kleinen/mittleren) Kunden vorbei ohne eigene Entwicklungsabteilung die einfach alles auf Core biegen kann und reine Eigeninteressen. Alles mit der Brechstange in ausgefeiltester Wegelagerer-Manier aufzwingen weil man es aufgrund Quasi-Monopol kann. Immer hart an der Grenze was gerade noch "gefressen" wird. Schön Häppchenweise damit man sich laufend daran gewöhnt. Einfach nur noch schade, stellen sensationelle Produkte her und versauen das ganze positive Bild wieder mit der ganzen Bloat-Ware die nun selbst in den Server OS eingezogen ist. Falls jemand versteckte Flags kennt wie man das wieder aktivieren kann ohne selber im Component-Store herumzuwüten wäre das klasse. Die Features "Server-Gui-Mgmt" und "Server-Gui-Shell" gibt es jedenfalls nicht mehr. Wenn jemand weiss wie man noch an die älteren Technical Previews kommt (meine ews war 3 oder 4 wos noch drinn war) dann wäre das Klasse. Habe meine dummerweise gelöscht. Grüsse und vielen Dank

Hallo Leute, Auf die Gefahr hin, dass ich das schonmal gefragt habe. Hat schon jemand mal versucht den Component Store von Windows 7 auf Level 8.1 anzuheben? Oder irgendwo was entsprechendes gesehen? Für ein paar Links wäre ich dankbar, irgendwie suche ich mich krum bei google. Kann mir aber nicht vorstellen, dass das ned schon jemand versucht hat. Ob Gefrickel oder nicht ist mir egal und soll hier auch nicht das Thema sein. :) Mittlerweile ist ja ne 0815-Installation mit Office und allen Updates bei irgendwo 40GB angelangt. Also sicher das doppelte, eher mehr, was irgendwie normal wäre. Die neueren Component-Stores lassen ja ein richtiges Cleanup von altem Schrott zu, was bei W7 noch nicht geht, bei W8 so halb und ab W8.1 eben richtig. Wäre mal interessant wenns da was pfannenfertiges gäbe ;) Grüsse und Dankeschön

Start einer Exe / Zugriff via BranchenApp: Dann brauchst auch keine RDP-Lizenzen bzw. TS. Wenn der Speed ausreicht mit angestarteter EXE würde ich mir das so oder so ersparen wenn es unterstützt wird. Fallen die ganzen zusätzlichen Kosten für RDP-Lizenzen, Hardware, zusätzlicher Einrichtungsaufwand für allfällige Virtualisierung etc. weg. Ich würde das folgendermassen machen: - 16 oder 32 GB RAM (auch 64 kostet nich mehr die Welt - wird aber oversized sein) - RAID 10 mit Hardwarecontroller sowie Batterie und mindestens 4x 15k SAS Platten für die produktiven Daten - Ein RAID 1/10 mit 2 oder 4 NL Platten für Hostinternes Backup - Ein kleines NAS mit 2 oder besser 4 Platten in anderem Brandabschnitt - LAN-Verkabelung im Büro ausmessen lassen ob gut Gigabit-Tauglich, falls nein ersetzen Dann wird es mit grosser Wahrscheinlichkeit auch mit der aus dem LAN gestarteten Applikation recht flüssig laufen.

Gut, dann bleibt noch die Frage zu klären wie sie tatsächlich auf den Server zugreifen. - Tablet/Smartphone: Direkt mit der Branchen-App oder holen sie sich den Desktop des Servers via RDP? - Arbeiten im Brüo am PC: Mit lokal auf dem Client installierter App oder wie genannt via App die per LAN gestartet wird oder soll/muss direkt auf dem Server gearbeitet werden? Das vernünftigste für Mehrbenutzer-Zugriff ist normalerweise eine Client-Server Lösung. Also Desktop-Installation für die User und auf dem Server die DB/Daten. Darauf arbeitet dann niemand direkt. Auch OK ist dann Terminalserver, mir schmeckt das aber gerade in Kleinstumgebungen wo dann meist nur eine Server-Instanz läuft nicht wirklich. Will ja nicht die User direkt auf dem DC haben. Die anderen Dienste zwar eigentlich auch nicht parallel zum DC, aber wenigstens keine Anwendungsprogramme und Nutzer. Korrekterweise müsste man den TS in eine eigenen Serverinstanz verfrachten. Das wird dann aber wieder aufwendiger weil entweder zwei PC's oder virtualisierung mit dem ganzen Rattenschwanz. EXE aus LAN anstarten ist je nach Software grottenlahm oder eben schnell. Wenn DNS passt liegt es meist am Programmdesign worauf Du keinen Einfluss hast. Problematik ist dann in aller Regel das jeweils Gesamt-Tabellendaten und nicht aufbereitete Daten übertragen werden. Dann ist oft wirklich nur ein TS oder eben virtuelle Desktops auf dem gleichen Host wie der Server wirklich brauchbar. Das heisst: Wenn anstarten aus LAN genügend OK ist oder auch ein Client/Server System installiert werden kann: Essentials oder Foundation kann ausreichen.

Was genau willst Du? - Die Geschwindigkeitsprobleme lösen? - Gemeinsamer Datenbestand? - einfach eine zentrale Installation? - Von unterwegs oder nur im Büro darauf zugreifen? - Mehrere Leute parallel darauf zugreifen? Geschwindigkeitsprobleme lassen sich bei manchen Branchensoftware nicht so einfach lösen. Oft ist dann tatsächlich ein TS zielführend. Manchmal ist es aber auch sinnvoller Desktop OS sowie Server OS auf einem Host zu virtualisieren. Der Traffiic läuft dann komplett Host-intern ab. Das ist rasend schnell. Das geht dann aber im kompletten in die tausender und nicht hunderter Wenn das Geld nicht so locker sitzt gibt es eigentlich nur eine vernünftige Lösung. Ein physischer Client mit der Software drauf. Wer die Software braucht, geht an diese Maschine. Mehrplatz mit gemeinsamen Datenbestand ist immer der Spielplatz von teureren Lösungen. In jeder Hinsicht. Hardware, Einrichtung, Lizenzkosten etc.

Oh, gar nicht gesehen... Klar ist Veaam oder ähnliches nochmals besser. Vor allem in Sachen Monitoring einfacher bzw. Out of The box ohne selber Trigger auf Windows-Ereignis zu schreiben. Ist halt nochmals eine zusätzliche Komplexitätsteigerung der Umgebung. Zudem sind die Repositories der Lösungen technisch teilweise auch recht komplex . Dem muss ja auch wieder Rechnung getragen werden sonst nützt das ganze Backup nix wenn ein Stromausfall ein Repository möglicherweise unbrauchbar macht. Wie anfällig da Veam und Konsorten sind weiss ich aber ned. Zudem finde ich es persönlich einfacher und sicherer direkt einen Restore vom internen Speicher zu fahren ohne das eigentliche Backup anzutasten und vom lahmen NAS anzustarten. Ein Host-internes Recovery ist ratzfatz gemacht wenn man mit schnellen Speichern arbeitet. Die angestartete VM muss ja dann auch wieder auf den produktiven Store verschoben werden. Wenn wirklich ein Desaster eintritt wie Brand, hat man eh ganz andere Sorgen als die IT in 1-2h wieder hochzuziehen. Nicht ausser Acht lassen sollte man bei einer solchen Direkt-Start-Lösung auch die Lizenzkosten für MS. Normal will MS dann zusätzlichen Lizenzkosten sehen wenn der Host nicht dauerhaft geändert wird. Ausser ich bin da nicht mehr ganz auf dem aktuellsten Stand. Aber da hat jeder seine eigenen Herangehensweisen. Wenn das Budget knapp ist, ziehe ich die simple Bordmittel-Variante vor und verwende das Geld lieber für einen zusätzlichen internen Controller als für eine externe, professionelle Backuplösung.

Die Performance ist wie die Vorredner schon sagten, selten berauschend mit USB. Unter HyperV meist besser als mit ESXi Daher nehme ich fürs Backup eigentlich auch immer eine Kombination aus internenem Storage und einem NAS. Das NAS ist für den richtigen Desasterfall bei Brand oder so und der zweite interne Storage für das schnelle Recovery. Das ist eigentlich auch bei kleinen Umgebungen immer finanzierbar und im Gegensatz zu eher grossen Umgebungen zieht das keine Wahnsinnigen Kosten mit sich weil Speicherplatz meist eh genug vorhanden ist. Läuft dann so: - Interne Platten im RAID 1 (10) für die produktive VM's - Interne Platten im RAID 1 (10) für das Backup (optimalerweise separater Controller - ich nehme normal nen Hardware-RAID-Controller mit NL-Platten)--> zusätzliche virtuelle Disc in die VM - NAS mit NFS (Zweiter Windows Server oder günstiges QNAP, Synology etc.) --> NFS an Hypervisor anbinden, zusätzliche virtuelle Disc in die VM - Nach der Erstinstallation oder grösseren Änderungen fahre ich die VM's herunter mache ne Cold-Kopie aufs interne Storage und fahre die VM's wieder hoch. Danach die Kopien via FileCopy noch auf das NAS schieben. - Je nach Budget und Anspruch dann eben noch nen zweiten Fileserver mit deaktivierten Ordnerzielen auf denen Windows mit DFS repliziert. Kann dann schnell umgeschalten werden ohne Recovery. Somit ist 1. Storage-Logik komplett von der VM entkoppelt und im Hyper-Visor abgebildet (ob das nun HyperV oder ESXi ist) 2. Restore-Aufwand hält sich arg in Grenzen weil einfach die virtuelle Backup-Disc als normale Festplatte in eine neue oder bestehende VM eingebunden wird. Also kein Gehampel mit USB oder iSCSI. 3. Allfällige zusätzliche Copy-Jobs auf externe Datenträger sowie Copy-Back sind easy und vor allem schnell weil direkt die kompletten Festplatten als einzelne Files kopiert werden können und somit die Daten sequentiell und nicht per random 4k übertragen werden. 4. die Filesysteme wo die virtuelle Discs drauf lagern sind sehr robust. Egal ob Windows oder Linux. Datenverlust ist auch bei einem Stromausfall eher unwahrscheinlich. Im Gegensatz zur Anbindung via iSCSI via nem günstigen NAS bei ESXi. 5. Komplexität hält sich in Grenzen, ein Recovery kriegt meistens auch jemand mit telefonischer Anweisung vor Ort auf die Reihe. Mit Fernwartung sowieso. Das NAS habe ich bis jetzt bei keiner der Umgebungen für nen Recovery gebraucht. Auch nicht bei nem Mainboard-Ausfall. Testweise habe ich auch schon Versuche mit Ethernet to USB Adapter gemacht. Ist aber nur bei HyperV beschränkt sinnvoll da halt Preiswert. Dazu wird die Platte per Treiber als lokale Platte eingebunden obwohl sie weit entfernt ist (anderer Brandabschnitt). Darauf dann die virtuelle Disc für das interne Backup der VM. Übertragungswunder kann man aber auch da nicht erwarten. Bei ESXi würde es mit einer zweiten VM funktionieren indem wiederum per NFS der Ordnerinhalt zu Verfügung gestellt wird. Das ist dann aber schon etwas arg gefrickelt und doch recht aufwändig fürs Recovery.

Es ist nicht so, dass die interne Sicherung nicht tauglich wäre. Im Gegenteil. Gibt halt nur Komplett oder gar nicht. Bei Exchange kann das mitunter schon ziemlich zeitaufwendig werden.

Recovery und Backup auf USB will man nicht via ESXi. Normalerweise absolut unbrauchbar langsam. Mit neuestem USB eventuell, aber das ist teilweise recht tricky zum einbinden. Würde das Konzept ändern. Sicherung auf ein NAS welches Du in ESXi einbindest, da drauf erstellst eine virtuelle Disc, welche Du wiederum dem SBS präsentierst. Somit liegt die Disc auf einem robusten Dateisystem ob nun NTFS oder ein Linux-Derivat. Vorteil: Du kannst auf einfache und vor allem schnelle Sequentielle Copy-Jobs zurückgreifen um das File vom NAS auf eine zusätzliche externe Platte zu schieben. Ist das NAS ein Windows Server sogar ohne grossartig benötigtem KnowHow. Die Disc ist dann einfach nen File. Auch ein Disaster-Recovery ist entsprechend massiv schneller, weil je nach Umstand sequentielles Copy verwendet werden kann.

In kann es nur wiederholen, eine SBS-Migration spielt man direkt mit einem ColdClone in einer Testumgebung durch und dokumentiert die Schritte. Wenn fertig, schaltet man das Produktivsystem aus, hängt die migrierten VM's ins richtige Netz, fährt ein paar Tests und dann gehts entweder mit dem Migration-Test-System weiter und aktualisiert die Daten oder fährt die dokumentierte Migration am Produktivsystem. Wenn man keine Erfahrung hat sowieso, alles ander ist Wahnsinn. Bei Erfahrung kann das ColdClone auch einfach als richtiges "Status Quo" vor der Migration herhalten. Am besten auch das Testsystem in einem physischen getrennten Netz/PC. Dann schiesst man die DC's nicht gegenseitig ab wenn man Fehler in der Netzwerkkonfig macht und beide online sind und sich sehen. Als erstes solltes Du endlich mal ein ColdClone ziehen bevor ihr noch mehr kaputt konfiguriert. Des weiteren sollte tunlichst die Backups zusätzlich weggesichert werden, nicht das ihr da noch alles zerstört. Je nach dem welche Replikation Du überhaupt meinst (ohne genau Fehlernummer bringt das nix) ist entweder AD selbst oder nur die zugehörigen Files betroffen. Ich vermute mal die Files. Wurde auf DFS-Replikation anstelle der FRS Replikation umgestellt (Migration von 03) oder standardmässig vorhanden (Neuinstallation) ist das sogar sehr wahrscheinlich. Da braucht es nicht viel, damit es nicht mehr arbeitet. GPO's und Scripts wurden dann käumlich sauber repliziert als Du den neuen DC aufgenommen hast, auch wenn das AD an sich in Ordnung zu sein scheint. Wirst dann erst merken wenn der SBS aus ist oder die Clients unterschiedlich reagieren. Wenn es an AD selbst liegt und es sich nicht mehr reparieren lassen würde bzw. ihr das nicht hinkriegt und auch keine externe Hilfe wollt, würde ich mal nen Backup vor der Migration in eine Test-VM zurückspielen und schauen ob da AD noch in Ordnung war oder ob es auch schon Replikatfehler hatte. Des weiterne würde ich eine E-Mail Weiterleitung auf euren Provider einrichten. Dann habt ihr im Falle eines kompletten Rollbacks oder sonstigen Problemen wenigstens noch die aktuellen Mails. Könnt natürlich auch alles neue in Outlook exportieren und nach erfolgreicher Migration neues wieder importieren. Sind aber alles Basis-Vorgehensweisen die man sich mit Testsystemen aneignen sollte bevor man sich an die produktiven Systeme wagt.

Was genau meinst Du wenn Du von "Was das Tool wirklich macht" sprichst? Warum willst Du als erstes die Betriebsmaster etc. übertragen? Das macht man meines erachtens normal am Ende wenn der Rest alles geklappt hat und astrei funktioniert. --> Zumal Du es dem SBS austreiben musst wenn er nicht dauernd neu starten soll bevor Du die Rolle überträgst. Ist dein AD überhaupt in Ordnung bevor Du auf einen neuen DC replizierst? Hast Du Probleme mit der Replikation des AD nachdem du den neuen DC in die Domäne aufgenommen hast? Funktioniert den DNS von und zum SBS von der Maschine her die neu DC sein soll? Der Replikationsfehler liegt vermutlich an der (fehlenden) DFS-Replikation aufgrund eine ungeplanten Shutdowns oder so. Also zuerst mal die manuell wieder aktivieren. Dann musst hier mal nach Acitve Directory DFS-Replikation suchen. Gibt zuhauf Threads dazu. Soweit ich mich erinnere war die schon aktiviert beim SBS 2008 wenn er nicht von 2003 migriert wurde. Solltest hierzu aber Fehler im Ereignislog habe Nur mal so: Hast Du neben dem Backup (das mit fast 100%iger Sicherheit nicht 1A ist wenn Applikationen nicht separat gesichert wurden oder mit der SBS-Konsole) auch ein ColdClone gezogen? Also VM ausschalten und alles Copy als Sicherheit?