Weingeist

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

Naja, mit der richtigen darauf spezialisierten Software klappte das in der Vergangenheit astrein. Da war der Support dann via dem Hersteller der Replikat-Software gegeben. Insbesonder für den SBS war das früher sehr interessant. Ob HyperV Replika dafür das richtige Instrument ist, will ich nicht beurteilen. Ansonsten: Bei den Preisen von extrem schnellen lokalen Speichern und den normalerweise üblichen Speichermengen die man im SBS Umfeld braucht, sehe ich den Sinn von Replikaten nicht mehr so wirklich bzw. überwiegen die Nachteile von Replikaten deutlich gegenüber der zusätzlichen Investion in ein potenteres Backupsystem. Bei grösseren Datenmengen einfach den Fileserver separat halten und mit DFS-Repliakten arbeiten wenn schnelles Recovery bzw. Back-ToWork-Zeit gefordert wird. Der SBS selbst ist dann in kurzer Zeit wiederhergestellt sofern er überhaupt noch eingesetzt werden soll.

Sicherung ist schon eingerichtet ja, wurde schon vor meiner Zeit gemacht. Sieht soweit gut aus. Auch das "Aufräum-Script" war schon da. Insofern eigentlich schon in Ordnung wie das ganze aufgebaut und gemacht war. Nur die vielen Auto-Genehmigungen waren extrem auch wenn immer wieder gelöscht wurde. Das Aufräumscript hat hier zwar ganze Arbeit geleistet für den Content, die DB selber wurde auch immer reindexiert etc. die XML Tabelle ist aber komplett zugemüllt. Vermutlich ist das schnellste den WSUS einfach neu aufzusetzen.

Hmm wäre in der Tat eine Idee. Ich mache nie automatische Genehmigungen und begrenze die Produkte wos irgendwie geht sonst läuft der Content als auch die DB eh Ratzfatz aus dem Ruder wenn mehr als ein Client und Server OS verwendet wird. Auch wenn mir manchmal schleierhaft ist, wozu dermassen viel Daten gespeichert werden für die handvoll Updates. =)

Hi, 10'000MB und ein paar verquetschte. Läuft leider schon auf nem 2012 Express. Waren halt viel zu viele Genehmigungen und Produkte aktiviert, anders kann ich es mir nicht erklären wie man in so einer kleinen Umgebung eine so riesige DB hinkriegt.

Also nach kurzer Recherche müsste es - wohl das erste mal überhaupt in der Geschichte von DPM - möglich sein mit der aktuellen DPM 2016 Version auch die brandaktuelle Server 2016 zu sichern. Scheint gaaaaaaanz neue Info zu sein ;) Zumindest sind die DPM-Agents auf der MS-Seite gelistet. Das heisst normal das sichern möglich ist

Hallo Leute, Habe ne kleine relativ heterogene Umgebung übernommen und wollte da mal etwas aufräumen heute. ;) Nun habe ich mühe mit dem WSUS. Problem ist, es gab eine Säuberungsscript (das was eh fast alle verwenden) nur werden Updates die obsolet sind, nicht gelöscht. Das heisst die XML-Tabelle ist riesig und füllt die komplette DB. Die SyncTabelle oder die Event-Tabelle wurde dagegen regelmässig gelöscht. Auch die Indexe neu aufgebaut. Das heisst keinerlei Spielraum mehr auf der DB. Sie ist komplett voll. Ein SPDeleteUpdate schlägt direkt fehl in Ermangelung von Speicherplatz der dafür benötigt wird. Also nicht der übliche Befehl wo via TempTbl alle ID's rausgeschrieben werden um sie anschliessend abzuarbeiten, sondern bereits wenn man nur ein einzelnes Update so löeschen möchte. Die GUI-Variante funktioniert logischerweise ebensowenig. Jemand ne Idee wie ich etwas Speicher freischaufeln kann ohne den WSUS neu aufsetzen zu müssen? Die Internetleitung ist zudem recht lahm, da ist es schon noch ein Wort den kompletten Content wieder herunterladen zu müssen. Mir fällt leider grad nur noch ein die DB auf nen richtigen SQL-Server mit zu transferieren, zu säubern und wieder einzuspielen. Ist aber auch ziemlich mühsam. Vielen Dank für Inputs

Na die entwickeln sicher parallel aber die Testphase dürfte deutlich länger sein beim Backup-Produkt. Bei manch anderen Produkten sind ja mittlerweile die Kunden die Betatester. Zumindest kommts mir seit ungefähr 2 Jahren bei manchen Produkten von MS so vor. Daran wird sich wohl auch nix mehr so schnell ändern wenn sogar die Abteilung die extra fürs Update-Testen ins Leben gerufen wurde aus Kostengründen aufgelöst wurde... Da ist dann die langfristige Strategie schon erkennbar. ;)

Die DPM-Abteilung hinkt in aller Regel etwas hinterher. Ist ja auch logisch, eine Backup-Lösung sollte defninitiv Hand und Fuss haben. Irgendwie zum laufen bekommt man ja fast immer alles, ob es dann sinnvoll ist, steht auf einem anderen Blatt. Bin jedenfalls froh wenn es noch Abteilungen gibt, wo zumindest versucht werden darf die Updates durchzutesten. Bevor ein Produkt wirklich freigegeben ist, ist das ja nicht möglich. ;)

Mir gefällt vor allem folgender Satz: "Every Windows update is extensively tested with our OEMs and ISVs, and by customers – all before these updates are released to the general population." Auch wenn der Anhang - wies mir in letzter Zeit vorkommt - eher nicht zutrifft und das fettgedruckte überwiegt.

@testperson: Das kommt ganz auf die Übertragungsrate an. Die virtuelle Netzwerkkarte ist immer direkt abhängig von der CPU solange nicht Direct Path I/O genutzt wird. Nur fällt das normalerweise gar nicht auf, weil man in einer einzelnen VM meistens eh ned soviel Leistung abruft bzw. abrufen kann. Ich erreiche die CPU-Limitierung auch nur Hostintern auf den SSD-Primär- und Sekundärspeichern, da läuft nichts via externer Netzwerkkarte ab sondern nur hostinern im Netzwerk-Stack. Da muss aber ohne Direct IO alles drüber. Extern habe ich kein Storage welches diese IO-Leistung auch nur Ansatzweise verarbeiten könnte geschweige denn die entsprechende FC oder oder sonstige Lösung ;) Habe das auch nur Testweise gemacht zum sehen wo tatsächlich ende ist, wollte produktiv ned so viele Kerne der Storage App "opfern"

Ich meine das war ziemlich Host abhängig. Andere Leute berichteten es genau anders rum. Auf manchen lief das eine besser auf dem anderen jenes. Auf meinen Hosts (Fujitsu und Supermicro) hatte ich mit E1000 nie wirkliche Probleme unter 5.1, nur ne Menge Log-Einträge. Tat aber der Performance oder Stabilität der Verbindung keinen Abbruch. Wie auch immer, VMXNET3 kann und sollte aktuell wohl generell verwendet werden. Funzt am besten. @magheinz: Die Übertragungsrate ist vor allem auch CPU-abhängig. Die Rate skaliert mit VMXNET3 linear hoch wenn mehr CPU-Kerne verfügbar sind. Höhere Takrate bringt dagegen mehr als nur linear etwas. Immer vorausgesetzt, dass das Storage auch die notwendigen IOPS bereitstellt. Davon bin ich auf meiner SAN weit entfernt aber auf meinen hostinternen Storages komme ich bei Recovery oder Backup bis fast an die Herstellerspezifischen Angaben der SSD's in RAID10 ran. Skaliert dann ebenso nahtlos wenn mehr SSD's im selben Stripe sind. Braucht dann aber auch ein paar 3GHZ Kerne in der Quelle und im Ziel. @Ulupus: Vorher vergessen, Treiber für VMXNET3 sind Bestandteil der VmWare Tools

Das Problem sehe ich jeweils im im Automatismus der gerne mal fehlschlägt. Vielleicht bin ich ja zu doof aber ich hatte das öfter, dass die VM's irgendwas gerödelt haben und einfach viel zu lange zum runterfahren hatten. Vor allem der SBS war da grässlich. Liess sich zwar verschnellern mit manuellem Shutdown-Script war aber immer noch super mühsam. Auch SAN Shutdown ist irgendwie uncool. Wenn die HDD's vielleicht nach Jahren nimmer hochfahren wollen auch. Gabs wohl auch schon. =) Ich habs am liebsten wenn ich möglichst nie runterfahren muss. Hab ich keine Arbeit damit und muss ned nervös werden wenn ich mal ned da bin. Wo wir grad bei den sinnvollen Dingen sind: Eigentlich wäre auch ein UMTS-Gateway für Fernwartungszugriff gut. Internet ist dann in der Regel auch essig wen es grössere Stromausfälle sind, die Handymasten haben oft ne recht lange zeit Notstrom oder sind eigens versorgt weil mittlerweile Katastrophen oft darüber laufen. Die Batterien halten problemlos 10 Jahre wenn die Bedingungen stimmen. Also Überkapazität damit sie im normalfall gar nie tief entladen werden sondern max. bis ca. 30%. Dazu am besten klimatisiert. Die einzelnen Batterien sollten auch mindestens 40Ah haben, ab da ist ca. die physische Qualität um einiges besser weil die auch in Fahrzeugen und Baumaschinen verwendet werden. Die guten müssen da viel aushalten können. Sowas kriegt man aber leider ned für die kleinen USV's sondern nur bei den grossen Brummern oder solche die auf Bestellung gefertigt werden. Oder eben Batterie-Pack Marke Eigenbau, dann aber vorzugsweise mit Abnahme wegen Versicherung und so.

@Zahni: Naja, hab ja alles auf Intel gewechselt und nix mehr auf VMXNET3, von daher wäre mir das nicht aufgefallen, dass VMXNET3 wieder geht auf 5.1 ;) @Ulupus: VMXNET3 hängte sich unter 5.1 gerne mal auf. Performance war urplözlich und ohne Vorwarnung im Keller. Half nur ein Ausschalten und Reboot der VM. Angeblich gefixt wurde es öfter mal. Irgendwann hatte ich genug von den angeblichen Fixes und hab alles auf E1000 gewechselt und auch nichts anderes mehr konfiguriert. Probleme waren komplett weg. Daher ists/wäre es mir nicht aufgefallen wens mal tatsächlich richtig gefixt wurde. Nach dem Wechsel auf 5.5 wars dann gleich anders rum, alle VM's machten mit der Zeit Probleme. Auf dem gleichen Host. Ob aktuell E1000(E) unter 6 oder 5.5 sauber läuft weiss ich nicht, habe da nach den ersten Problemen nur noch VMXNET3 genommen und alles wieder zurück gewechselt.

Der E1QEXPRESS ist ein Standardfehler. Meiner Erfahrung nach ist es meistens sogar total egal wenn der kommt, ist nur super nervig weil er alles zumüllt und wichtiges übersehen wird (wegfiltern). Manchmal kommt er auch weil er irgendwelche Updates fahren will bzw. keine Treiberdownloads machen darf wegen Policy-Beschränkungen. Kommt manchmal auch wenn alles wunderbar funktioniert und sämtliche Energiesparfunktionen abgeschaltet sind. Abstellen lässt er sich nur zuverlässig indem man den Gerätesammeldienst inklusive zugehörigem Task deaktiviert der eh total für die Katz ist. Dann ist Ruhe im Karton. =) Je nach ESXi Host ist aber der Wechsel auf VMXNET 3 tatsächlich sinnvoll, das äussert sich dann aber mit richtigen Unterbrüchen und spürbaren Performance-Einbussen. Auf meinen 5.1 Hosts war die Intel-Karte deutlich stabiler, auf 5.5 wiederum VMXNET3. Auf dem gleichen Host wohlverstanden. Verstehe das wers will.

Dem kann ich nur beifplichten. Stromversorung ist das A und O. In meinem Bekanntenkreis haben sich in den letzten 5-10 Jahren die Stromausfälle massivst erhöht. Einfach weil Netzausbau eben teuer ist. Von daher: bevor ich irgendwelche Hochverfügbarkeitsdinger in Erwägung ziehe, erstmal Grundlagen für eine stabile Stromversorgung schaffen. 2 USV's mit viel Batteriekapazität damits auch ein paar Stunden autonom läuft wenn z.B. Shutdown aus welchen Gründen auch immer in die Hose geht. Die Batterien dankens einem auch wenn sie ned jedes mal auf 0-20% entladen werden --> sehr schnell doppelte bis dreifache Lebensdauer. Dazu ein einigermassen schnelles Recovery.

C&C, da wird mir gleich warm ums herz =) Mods programmieren und unverfügbare Einheiten irgendwie zum laufen zu bekommen, Gegenerische Einheiten stärker machen usw. hat mächtig Spass gemacht und viiiiiiiiiiiiele Nächte gekostet. Ist ja leider heute jeweils alles verschlüsselt :( Zum Thema: Windows 98 läuft eigentlich nur auf VmWare wirklich gscheit. Ich kann die Version Workstation 6.5 (neuest Build) mit einem XP Host empfehlen, ist zwar schon älter, läuft dafür aber extrem stabil, schnell und ohne Mäzchen. LSI-Treiber gibts im Netz (mit etwas suchen) der Graka-Treiber kommt von VmWare. Simple 3D-Grafik funktioniert recht gut. Halt auf die Befehle beschränkt, die unterstützt werden. Mit XP oder Server 2003 als Unterbau läufts zudem flüssig. Mitunter muss etwas an den Parameter der VM geschraubt werden für ein optimales Ergebnis.

Wenn der Standarddrucker mit Rundll32 als letztes gesetzt wird, bleibt er auch der Standardrucker. Ausser man pfuscht mit was anderem rum. :)

Wie gesagt, nimm die uralten rundll32 Befehle mit nem Batch-File oder die gleichen mit nem VBS. Solange man keine anderen Scrips und GPO's rumpfuschen lässt, funktionierts auch. Ich habe die Probleme in keiner einzigen Umgebung und sind auch ein paar davon mit aktuellem 2012R2. Ob die Dinger nun in der Geräteliste auftauchen oder nicht ist doch total egal solange sie in den Programmen sowie der effektiven Druckerliste erscheinen (auch wenn diese nur über einen Umweg - siehe unten - erreichbar ist) Diese Geräte-Liste ist dermassen Buggy, dass man darauf eh keinen Cent geben sollte. Wenns nur um die geht, verstehe ich das Problem daher eh nicht =) Kenne bist jetzt jedenfalls kein Programm, dass sich die Liste darüber holt. Wenn du eine funktionierende Liste willst, die "richtige" Auflistung hernehmen: Ordner erstellen mit: "Druckerliste.{2227A280-3AEA-1069-A2DE-08002B30309D}" Darauf dann ne Verknüpfung und diese ab ins Starmenü oder Desktop. Der Name vor der GUID ist irrelevant. Ist erst noch viel bequemer um Einstellungen zu erreichen oder Drucker zu löschen.

Nimm doch einfach ein gutes altes Login-Script für die Printer. Normalerweise sind die Probleme dann gelöst. Ich habe jedenfalls keinerlei Sorgen mit verschiedensten Drucker. Set PrintingServer=\\SV-Printer-2012 rundll32 printui.dll,PrintUIEntry /in /n %PrintingServer%\PrinterName1 rundll32 printui.dll,PrintUIEntry /in /n %PrintingServer%\PrinterName2 REM Standardrucker setzen rundll32 printui.dll,PrintUIEntry /y /n %PrintingServer%\StandardruckerName1 REM alte löschen (ich aktualisiere die Liste bzw. entferne nach einiger Zeit die Einträge wenn mehr oder weniger alle mal wieder angemeldet waren, gleichzeitig pro Umgebung eine Liste mit allen alten Druckern wenn sich mal wieder einer ne Ewigkeit nicht angemeldet hat und jammert er habe inaktive Drucker) rundll32 printui.dll,PrintUIEntry /q /gd /n \\%PrintingServer%\PrinterNameZuLoeschen1 rundll32 printui.dll,PrintUIEntry /q /gd /n \\%PrintingServer%\PrinterNameZuLoeschen2 Ist auch für einige Arbeitsplätze gut geeignet, meistens pro Abteilung nen Script.

Kein Grund dauernd abschätzig über Klein- oder Kleinstfirmen zu sprechen. Es spielt keine Rolle ob 3, 10 oder 100 Mann Bude. Die Bloatware und Auspioniererei gehört einfach nicht auf die Arbeitsmaschinen. Die Pro-Version war eine Business-Version und davon gehen die meisten noch aus. Die Pro-Version wird bewusst grottig gemacht um sie den Business-Benutzer möglichst madig zu machen. Quasi der gleiche Plan wie bei VM's, Office und Application-Servern. Langsam einen um den anderen in die Miete drängen. Erst mit kleinen lästigen Dingen wie dem Lock-Screen, Bloatware die sich nur schwer entfernen lässt etc. Später werden dann noch mehr Einschränkungen hinzukommen. Auch bei den Enterprise und sogar der Enterprise LTSB Versionen hat es noch ne Menge Datensammlungskrempel mit an Bord wer da - wie ihr so schön sagt - nicht "rumfrickelt" gibt eine sehr grosse Menge an Daten bekannt. MS darf mit den Windows 10 Bestimmungen so gut wie alles, auch wenn sie die Möglichkeiten noch nicht ausschöpfen, es wird bestimmt noch gemacht. Erst mal möglichst viele umsatteln und dann langsam die Schraube anziehen. Ist nicht mehr weit weg von vertraglich zugesicherter Werksspionage. Wie gesagt, dank immer sauberer Kapselung seitens MS kann man heute den unerwünschten Krempel meist auch problemlos löschen ohne Systeminstabiltät befürchten zu müssen. Das war früher teilweise eine mühsamere Angelegenheit. Macht man die Änderungen sauber per Script, kann man sie auch auf Knopfdruck wieder rückgängig machen. Alle die das als Frickelei ansehen, ignoriert doch die Thread's dazu einfach und hebt die Energie für andere in euren Augen sinnvolle Threads auf. ;)