Jump to content

Weingeist

Members
  • Gesamte Inhalte

    1.627
  • Registriert seit

  • Letzter Besuch

Alle erstellten Inhalte von Weingeist

  1. 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
  2. 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
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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?
  12. 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.
  13. OK, Dankeschön. Ne billig ist das sicher nicht, vor allem wenn zwischen Storage und den eigentlichen Server unterschieden werden soll.
  14. 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.
  15. 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. ;)
  16. 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
  17. 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.
  18. 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.
  19. 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. =)
  20. 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.
  21. 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
  22. 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
  23. 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. ;)
  24. 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. ;)
  25. 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.
×
×
  • Neu erstellen...