Weingeist

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?

Gscheit ist immer relativ. Ich kann es nur wiederholen, ich persönlich halte Storage Spaces mit entsprechender Hardware technisch durchaus für gscheit. Andere sind da zwar anderer Meinung aber meine Erfahrungen könnten besser fast nicht sein. Allerdings ist da der grösste Vorteil schon im Value for the Bucks. Wenn nun durchs Band Datacenter benötigt wird, schränkt das schon arg ein wie ich finde. Ansonsten: Da ich von den bisherigen SS Funktionen absolut überzeugt bin und mittlerweile auch schon einige Jahre bei verschiedenen Installationen im Einsatz habe, traue ich MS zu, dass auch diese neue Erweiterung technisch 1 A funktioniert. Fragezeichen habe ich ausschliesslich beim Support wenn mal was vergeigt wird. Der ist bei den klassischen Storage-Herstellern in aller Regel sehr kompetent. Auch als kleiner Kunde. Das kann ich von MS in letzter Zeit nicht unbedingt behaupten. Da ist es viel schwieriger geworden kompetente Leute an den Draht zu kriegen. Vor 10 Jahren kam man fast direkt ran. Aber diese Diskussion wurde schon x-mal geführt, auch von mir. Diese wollte ich jetzt nicht wieder aufflammen lassen. Mich interessiert im Moment alleine der technische Hintergrund und was darauf läuft. Der ist mir bei diesem Feature noch nicht so 100%ig klar.

OK, Dankeschön. Ne billig ist das sicher nicht, vor allem wenn zwischen Storage und den eigentlichen Server unterschieden werden soll.

Den SBS habe ich für Migrationen auf Standardprodukte jeweils auch nach und nach komplett "entschlackt". Das heisst erst ne ColdCopy gezoge und anschliessend alle unnötigen bzw. migrierten Applikationen nach und nach runtergeworfen. Bei der FSMO-Rollen-Übergabe die zugehörigen Dienste und Tasks die das Teil abschalten deaktiviert bis die Migration wirklich komplett durch war. Sobald man der Meinung ist an alles gedacht zu haben, das Teil runterfahren die Leute arbeiten lassen. Je nach dem kommen dann nochmals ein paar Reklamationen weil nicht alle Links via DFS liefen, irgendwo DNS fix hinterlegt ist usw. dann kann man als Sofort-Lösung das Teil schnell wieder hochfahren und in Ruhe den Fehler suchen bzw. an den enstprechenden Orten nachbessern. Da hat wohl jeder seine Methoden, für mich war das die einfachste.

Jo klar, aber selbst Entry-Level SAN's sind alles andere als billig. Gespiegelte. Auch wen mans nicht vergleichen kann. Aber wie ist der Aufbau technisch? Ist es so wie auf den schicken Bildern, dass es tatsächlich die unterste Storage-Spaces Stufe ist und was drauf kommt ist wurscht? Also werden sämtliche Cluster-Varianten (auch die alten) unterstützt? Also keine Beschränkung wie der Storage zu Verfügung gestellt wird? Also z.b. iSCSI, NFS etc. EDIT: Auf alle Fälle sieht es sehr interessant aus, vor allem der Hyper-Converged Teil. Evtl. kann ich dann doch wieder von VmWare zu MS wechseln. ;)

Hallo Leute, Hat das schon jemand ausprobiert? Habe ich das richtig verstanden, dass dies auf einem zusätzlichen Layer unterhalb der eigentlichen Discs angesiedelt ist? Sprich den Dingern isses wurscht was drauf läuft, also z.B. NFS, iSCSI oder sonst was? Schade das MS wieder zur alten Praxis zurückgeht und coole Features nur in Datacenter einbindet und nicht in Standard obwohl man vor kurzem noch gross geblufft hat, dass dies nun der Vergangenheit angehört. Nun braucht man aber eine DC Lizenz oder gar mehrere bei mehr Cores für eine (physische) Instanz auf einem Storage-Server. Grosses Kino. *kopfschüttel* Grüsse und Danke