Weingeist

Jop, Danke. Genehmigungen scheinen wirklich per Powershell zu gehen. Habe mittlerweile herausgefunden, dass es in der DB bereit eine Sicht gibt welche einem die ganzen Daten ausliest. So hat man nen Anhaltspunkt mit welchen Tabellen man arbeiten muss. Selber eine Liste pflegen habe ich nicht so Lust. Schafft man eh fast nicht mit allen Ablehnungen usw. Denke da eher an sowas wie von meinem WSUS alles auslesen und dann automatisch abarbeiten. Muss dafür natürlich alle definierten Spezial-Gruppen der Kunden auch bei mir vorhalten (Spezielle Maschinensteuerung welche nicht alle Updates erhalten dürfen z.B.). Am Ende sollt es dann quasi so ablaufen: Schau ob das Update in der Liste/Tabelle den gleichen Status hat wie in der DB, falls nein, ändere es. Bissel was gefunden habe ich dazu schon, zumindest zum setzen aufgrund einer CSV-Datei. Mal sehen was da sonst noch auftreiben kann. Was ich mich noch gefragt habe: Die SQL-DB scheint so aufgebaut zu sein, dass man mehrer Übergeordnete Gruppen wie die Gruppe "Alle Computer" haben kann, gibt es dafür eine offizielle Prozedur, kann man die direkt in der DB eintragen oder überwirft sich da die GUI? Bis jetzt konnte ich via GUI nur Untergruppen von "Alle Computer" erstellen. Hätte ich mir schon öfter gewünscht. Gerade für Spezial-Clients wie Industriesteuerungen wo ich gerne einen komplett separaten Stamm hätte, damit für gewöhnlich das "Alle Computer" trotzdem ausgewählt werden kann und nicht aus versehen nicht plötzlich doch was falsches genehmigt wird. Wäre sinnvoller als diese Clients komplett von WSUS und Windows-Updates abzuschotten, damit keiner dumme Sachen machen kann. Ist der interne WSUS zuständig und die Gruppe komplett separat, könnte man das gut steuern und auch ab und wann wieder gezielt Updates einspielen oder ablehnen.

Danke für die Antwort... Jo das ist schon so. Aber alle Kundennetze mit meinem zu verbinden finde ich nach reiflicher Überlegung aber eigentlich auch nicht so prickelnd. Bei einer solchen Verbindung werden aber im Haupt-WSUS immer alle Computer-Konten abgelegt oder? Und die Updates werden doch dann auch von diesem Master-WSUS geholt und nicht von Microsoft. Oder habe ich das falsch verstanden? Ob das lizenztechnisch geht weiss ich auch nicht so wirklich. Aber ich denke ich werde versuchen automatisch ein Script zusammenzustellen aufgrund der Einträge für die jeweiligen Updates in der SQL-Datenbank. Dürfte sicherer und einfacher zu realisieren sein. Muss ich nur herausfinden in welchen Tabellen die ganzen Angaben gespeichert sind. Hat evtl. schon jemand sowas gemacht und hat ne entsprechend SQL-Abfrage am Start?

Frag den Hersteller was für Bibliotheken er von Excel benötigt. Mit etwas Glück sind diese auch in der Runtime enthalten, dann kannst Dir das unter Umständen sparen. Ansonsten: Wenn Dir das alles zuviel ist, dann stelle eine Arbeitsstation hin wo jeder der in Frage kommt, seine Files erstellen kann. Und nur genau von dieser.

Hallo Leute, Gibt es eine Möglichkeit einen WSUS-Server quasi als Master für beliebige WSUS-Server in verschiedenen Domänen zu definieren? Er soll sich dabei nur die Genehmigungen von diesem Master-WSUS holen, nicht jedoch die Daten. Diese sollen nach wie vor via MS kommen. Geht das? Habe leider nix im Netz gefunden. Die entsprechenden Computergruppen müsste der Master-Server auch alle haben. Eine andere Idee wäre ein Script mit jeweils allen genehmigten/abgelehnten Updates mit Hilfe der SQL-Datenbank zu erstellen bzw. erstellen zu lassen und dann jeweils bei den Kunden durchlaufen zu lassen. Entweder direkt als SQL-Script oder über den Powershell-Umweg. Ziel der Übung wäre es, bei Kundensystemen nicht immer alles genehmigen zu müssen. Ansonsten soll aber nix übertragen werden, keine Dateien, keine Computerkonten etc. Jemand ne Idee oder schon gemacht? Vielen Dank

Ahja, was auf 2012 nicht laufen wird, ist soweit ich mich erinner deren Fernwartungstool. Musst Ihnen Teamviewer oder so schmackhaft machen. ;)

Orgamax verwendet eine eigene Datenbank. Ist alles sehr simpel gestrickt. Gehe mal stark davon aus, dass Du dem lahmen Ding etwas auf die Sprünge helfen willst. Aus eigener Erfahrung kann ich Dir sagen, dass der Server nur die Spitze des Eisbergs bedeutet. Der Client sollte ebenso ziemlich performant sein. Vorgehen: - Vollständiges Backup ziehen, sowohl mit dem Programm als auch per FileCopy (Es werden beim Backup NICHT zwingend sämtliche notwendige Daten gesichert. --> Manche speziell angepasste System-Formulare, die üblicherweise nicht verändert werden) - Datenbank in neuen Server recovern, Mandanten wieder aktivieren (sofern mehrere vorhanden sind, es werden standardmässig nicht zwingend alle mit korrektem Namen eingefügt) - Dateistamm mit Formularen etc. am besten mit CopyPaste komplett ersetzen, dann bist sicher, dass alles identisch ist, hab da leider auch schon anderes erlebt. --> Backupkonzept gleich mit anpassen. - Cients anpassen Bewährt hat sich ausserdem die Daten auf einer Windows-Freigabe bereitzustellen. Ist sogar DFS-tauglich. Hierbei aber bitte nicht wie empfohlen einfach auf alles erlaubt setzen, sonst kann jeder einfach das Rechnungsarchiv ziehen. Musst aber leider ziemlich viel offenbahren, sonst funktioniert es nicht zuverlässig. Performance: Die Software wurde in den letzten Builds immer langsamer. Vor allem die neue Übersicht braucht teilweise ewig zum laden. --> Tippe auf .Net Bibliotheken die zu lange brauchen oder in eine ältere Programmier-Runtime geladen werden. Auch wenn es mittlerweile leicht besser wurde. Problematisch ist vor allem, dass immer jede Menge Daten übertragen werden und nicht nur jene, die tatsächlich für die Anzeige gebraucht werden. Der Tipp das ganze für die Anzeige auf ein paar hundert Datensätze zu begrenzen bringt quasi gar nix. Auch wird das meiste vom Client berechnet und nicht vom Server. Willst Du also wirklich einen Performance-Schub, dann sollte nicht nur der Server sondern auch der Client über einen sehr schnelle CPU verfügen (nicht Kerne, sondern GHZ). Am schnellsten lief das Ding bis jetzt in einer virtualisierten Testumgebung wo der Client sowie der Server auf SSD's auf der selben Maschine lagen (E5 CPU, 3.2 GHZ). Der Netzwerktraffice geschieht dann Hostintern. Geht ab wie Schmitts Katz. Werden halt wieder Dinge wie gute Netzwerk-taugliche USB-Hubs notwendig für die Einbindung der Dokumentenscanner. -->Lizenzierung beachten Bezüglich Server 2012: Orgamax läuft astrei darauf, beachte in einer SBS-Umgebung, dass Du auch 2012 CAL's benötigst.

Es ist einfach viel entspannter. Keine Ahnung wie man es sich antun kann, jeden Client einzeln zu beglücken. Vor allem in Hinblick auf Updates die nicht erwünscht sind. Silverlight, Windows Desktop Search, Search 4.0 und ne Menge anderer Dinge die mehr oder weniger sinnvoll sind aber nicht zwingend gewünscht ist, dass diese generell ausgerollt werden. Nebst dem, dass man dann nie eine Ahnung hat, was genau auf den Clients installiert ist, wie sein Patchlevel ist usw. In WSUS hat man immer direkt den Überblick über alle Clients und Server. Zudem kann pro Computer-Gruppe definiert werden welche Updates sie erhalten sollen. Fragt sich halt, ob du mit 2 VM's tatsächlich bereits glücklich bist. Ich würde eher sagen nein. Folgende Dienste habe ich mittlerweile gerne getrennt: - WSUS - Printer - Kann eine Menge Ärger ersparen wenn mal nen Treiber spinnt und die VM einfach zurück gesetzt werden kann. Habe ich mir auch mit dem SBS angewöhnt da möglichst eine separate Instanz zu haben. - DC - Exchange - Datenbank Betriebssoftware Geht eigentlich mehr darum, dass beim SBS das als ganzes so verkauft wurde und man auch Support erhielt wenn was schief ging. Gewisse Dienste dürfen oder sollten heute nicht zusammen installiert werden. SBS war ein Konstrukt das super funktioniert hat weil sich eben MS die Mühe gemacht hat, alles so zu (ver)konfigurieren, dass es sich nicht oder möglichst wenig gegenseitig beisst. Das hat meiner Meinung nach sehr gut funktioniert. Zum Beispiel Veaam. Das sichert in einen Backup-Server und daraus kann man die Backup-VM grad anstarten wenn man möchte. Mir gefällt die Variante am besten, dass eine virtuelle Platte auf einem iSCSI, NFS oder ... in den Host eingebunden wird auf welchem dann per Hostsicherung oder mit einer zusätzlichen virtuellen Platte direkt aus dem Gast konventionell gesichert wird. - Mit Windows-Boardmitteln möglich - Die Storage Einheit kann bzw. sollte in einem anderen Brandabschnitt stehen - Recovery kann man z.B. nen Restore des Basis-Images machen, z.B. eine Kopie der Backupplatte einbinden und anschliessend den gewünschten Stand zurückspielen - Files halte ich jeweils gleich auf einer anderen Maschine vor was regelmässig Repliziert/Gebackupupt wird (DFS/Robocopy), im Desasterfall kann sobald der DC oben ist, einfach im DFS der Mirror-Pfad eingegeben werden und man hat mal alle Files wieder. --> Sind ja meist viele Daten und nicht so schnell restored Das ist verhältnismässig günstig, gut und die Komplexität ist überschaubar SQL-Server, Exchange, DC, Printserver. Gern geschehen

Hallo Zusammen, Kann mir jemand verraten was dieser Dienst und seine Tasks im Taskplaner genau machen? Nach einiger Recherche komme ich zum Schluss, dass diese Ding für sehr viele unnötige Warnungen verantwortlich sein muss. Es geht vor allem um folgende Events: Warnung 122: Der Zugriff auf Treiber auf Windows Updates wurde durch eine Richtlinie blockiert Warnung 200: Es konnte keine Verbindung mit dem Windows Update Dienst hergestellt werden Warnung 202: Vom Netzwerklisten-Manager wird fehlende Internetkonnektivität gemeldet Was die Warnungen bedeuten ist mir soweit klar. Ist auch gewollt so. Im Detail handelt es sich um die Aufgabe: "Metadata Refresh", sie lässt sich aber ned mal deaktivieren. Fragen: 1. Was tut diese Aufgabe überhaupt? Wozu ist es sinnvoll? 2. Kann man dem Ding irgendwie beibringen den Schnabel zu halten? 3. Fals man es nicht zum schweigen bringt, ist es ein Risiko die Aufgabe einfach zu deaktivieren? Vielen Dank

Da hast Du recht, hatte COPY:DATSOU mit /E und /Purge für MIR im Kopf... Nix für ungut und Danke für die Berichtigung.

@Daniel: MIR überschreibt aber auch alle Benutzerberechtigungen oder? Müsste man nicht die Flags selber zusammenbauen und Security ausklammer oder spielt das keine Rolle?

Ich betreue ja auch ein paar solcher Umgebungen und habe mittlerweile ein paar auf 2012 geswitcht. Meiner Meinung nach gibt es eigentlich nix bequemeres als nen SBS zu administrieren wenn man sich an ein paar Regeln hält sowie ein gscheites, mehrstufiges Backup/Recovery-Konzept hat. Hauptaufgabe ist unter WSUS die ganzen Updates zu checken/freigeben/kontrollieren. Der Rest ist ja ein ziemlicher Selbstläufer. Bis auf wenige Einrichtungs-Wizards oder Datenverschiebungs-Wizards habe ich wenig genutzt. Insbesondere die ganzen Logging-Funktionen habe ich jeweils möglichst abgedreht, weil der Ressourcenverbrauch in jeder Hinsicht jeweils ins unermessliche stieg. Das ist vor allem in VM's deutlich spürbar. Bis und mit 2003 war das Patchmanagement mitunter etwas "trickreich" wenn man zu den ersten gehörte. Seit 2008, VM's, Snapshots, VSS etc. ist das aber auch kein Thema mehr. Meine eher negativen Erfahrungen bis jetzt beim Wechsel - Das Patchmanagement hat deutlich an Aufwand zugenommen wenn Auto-Updated unerwünscht ist --> Mehrere Server - Die Gesamtkomplexität steigt - Für eine zackige Single-Host Umgebung mit schnellem Recovery muss einiges an Hardware aufgefahren werden --> Deutlich mehr OS Daten - Es braucht umfangreichere Reihenfolgen für Shutdowns und Starts (USV) sowie Überprüfungen - Um wirklich Vorteile und nicht nur Nachteile aus der Separierung der Dienste zu ziehen, braucht es eigentlich mehrere Hosts und VM's. -> Kostentreiber, SA etc. - Der Installationsaufwand ist deutlich höher - Desaster-Recovery-Aufwand bzw. die Zeit bis alles wieder oben ist, ist länger (ein paar neuere Backupkonzepte ausgenommen, wo direkt anstarten möglich ist) - Die Kosten sind deutlich höher Es hat natürlich auch einige Vorteile - Fehlersuche mitunter einfacher - Sicherheit sicher deutlich höher - Misratene Patches / Fehlkonfigurationen haben ned zwingend Aufwirkungen auf alles - Man kann nen Dienst einfacher entfernen und neu aufsetzen - Grössere Auswahl an Backupsoftware (Dafür auch deutlich teurer) Fazit: Ich arbeite nicht unbedingt weniger gerne so, eher im Gegenteil. Aber dieser Vorteil muss sich eben ziemlich teuer erkauft werden.

Bei Office gibts kein Reimageing mehr. OEM-Lizenzen sind heute weniger wert wie Volumen-Lizenzen. Der ganze Quatsch mit den KeyCards würde ich mir wie bereits erwähnt wurde in keiner Weise antun wollen. Das ist einfach nur mühsam. Zumal du Office 2013 verwenden musst, was ich persönlich ungefähr genauso gerne hätte. Mit einem Vol-Vertrag hast Downgrade-Rigths auf z.B. 2010... ;)

Wie bereits angetönt wurde ist das schwierig pauschal zu beantworten. Für Server-Workloads spielt es oft nicht so die Rolle. Aber es war schon immer so, viel hilft viel. Ist die CPU schnell, macht sie im Moment wo sie arbeiten soll, die Arbeit eben schneller, auch wenn ihr überspitzt gesagt 80% vom Tag langweilig ist. Das merkt man vor allem in VDI Umgebungen sehr gut. Das Benutzerfeeling ist deutlich spürbar besser wenn z.B. 2.2 GHZ und 3.2 GHZ verglichen wird, auch wenn die Leistung nicht permanent abgerufen wird. Anwendungen die vor allem SingleCore basierend sind oder aufgrund von Lizenzbestimmungen auf eine limitierte Anzahl beschränkt sind profitieren ebenso davon. Oft hat eine CPU die nur leicht höher getaktet ist, aber deulich mehr kostet, auch mehr Cache und/oder nen höheren QPI. Das wirkt sich auch auf die Performance aus. In kleinen Umgebungen oder für spezifische Workloads kann unter Umständen auch mal nen Single-Socket System mit ner dicken CPU eingesetzt werden. Die sind in der gleichen Serie deutlich billiger als jene für die Dual Systeme. Gibt halt nur nicht viele Hersteller die tatsächlich vernünftige Serversysteme mit den grossen E5 CPU's anbieten.

Theoretisch sollte das ja bei 2012 nicht mehr vorkommen. Aber Zahnis Tipp hilft normal bei dieser Fehlermeldung. Erweitere mal nur um 18 oder 19 GB.

DoubleTake machte seine Arbeit in der Vergangenheit sehr gut. Wie gut Sie heute sind, kann ich nicht sagen. War früher aber eine verhältnissmässig einfache Variante um nen SBS mit all seinen Diensten einigermassen schnell wieder bereitzustellen, Upgrades und Updates zu testen (einfach Syncro unterbrechen) usw. In der heutigen Zeit mit sehr gutem VSS sowie Snapshots mit VM's hat es aber arg an Bedeutung verloren bzw. kann man das gleiche günstiger und einfacher machen. Günstig war DT übrigens noch nie, Du brauchst für Basissystem und Endsystem ne Lizenz. Sowohl Windows und seinen Applikationen als auch von DT. Ob das ganze heute supported ist, weiss ich nicht. Ich würde in einer Kleinumgebung das Basissystem möglichst performant auslegen. Auch was Festplattengeschwindigkeit angeht. Dann sind Restores nach einem Defekt oder Austausch von Komponenten ratzfatz gemacht. Wenn Du viele Files hast, ist es in Kleinumgebungen ratsam, die ganze Filegeschichte auf zwei unterschiedlichen Systemen vorzuhalten. Replikation der beiden Systeme mit z.B. Robocopy oder DFS. Freigabe der Files mit DFS. Ein System ist dann in sehr kurzer Zeit wieder oben wenn nur das OS wiederhergestellt werden muss. Im DFS kann man dann einfach den Alternativort für die Files eintragen. Man kann das auch vorbereiten und das zweite Ziel einfach ind DFS deaktivieren. Dann haben die Leute keinen Zugriff darauf und bekommen das Ziel auch nicht zugewiesen. (Replikationskonflikte) Die Leute können jedoch sehr schnell wieder weiterarbeiten, weil die Files nicht erst wiederhergestellt werden müssen.

Hi Daniel, Vielen Dank für die ausführliche Antwort. Beste Grüsse ins MS-Land Weingeist

Du schlägst aber ziemlich aggressive Töne an, dafür dass Du nicht zu wissen scheinst was Du tust und Dich - wenn massig Warnungen kommen - immer noch keine Lust hast Dich zu informieren. Wie Du es machen sollst wurde genannt. Such halt im Netz, da findest Du massig Seiten die sich mit Backup und Recovery von Domainen-Controller befassen und was passieren kann, wenn Du Domänencontroller von einem Image wieder einspielst wenn noch andere DC's rumschwirren. Du kannst Dir sehr wohl einigen Ärger einhandeln. Mit meiner genannten Methode sind die Drucker innerhalb kürzester Zeit auf einen neuen Server umgezogen. Geht auch ohne Downtime wenn der Druckserver anders heissen darf wie vorher. Kommt auf die Anwendungsautomatisierung an. Mit kleiner Downtime von gehts auch mit dem gleichen Servernamen. Aufwendiger wirds wenn die Plattform von 32bit auf 64bit gewechselt wird. Sowohl Treiber und Einstellungen für Papierfächer, Briefköpfe usw. werden übernommen. Mit ner virtuellen Maschine ja sogar noch einfacher. Je nach dem ob Du den gleichen Servernamen verwenden willst oder nicht, halt etwas mehr Vorbereitungszeit nötig und direkter Erfolg zentraler oder auch nicht. Gleichen Namen empfiehlt sich, wenn eure Software automatisierte Druckabläufe mit einzelnen Drucker hinterlegt hat, die nicht so einfach zentral zu wechseln sind. Das meiste davon kannst Du vorbereiten, vorgängig in VM's testen. 1. Aufsetzen eines neuen Druckservers mit irgend nem namen, durchpatchen 2. Exportieren der Druckereinstellungen gemäss meinem Vorschlag (wie gesagt mit einem modernen OS auf den Server verbinden) 3. Import der Einstellungen auf den neuen Server (Ebenso via einem modernen Server oder Client, wenn nicht gleich ein neuer verwendet wird) 4. Herausnehmen des alten Druckservers aus der Domäne, kontrolle ob computerkonto gelöscht ist 5. Anpassen des neuen Servernamens auf den alten 6. Aufnahme in die Domäne 7. Anmelden der Clients mit nem LoginScript welches die verbundenen Drucker trennt und wieder verbindet. Zu 7. Entweder gibt es dafür bereits ein solches Script, es sollte erstellt werden oder Du hast Glück und es tut weiterhin wenn der Name identisch bleibt (was ich aber eher bezweifle). Bei neuem Druckserver-Namen eben Scripte vorbereiten. Wenn gar keine Scripte vorhanden sind und alles zu Fuss gemacht wurde für jeden Arbeitsplatz: Eben ein Script schreiben welches alle verbundenen Druckernamen erst ausliest, dann alle trennt und anschliessend wieder verbindet.

Dein Vorgehe ist extrem übel. Glück für Deinen Betrieb wenn das funktioniert hat. Keine Ahnung wie man alle Warnungen in den Wind schlagen kann und trotzdem so migriert. So wie Du das machst, kann man das bei einem einzigen vorhandenen DC tun, sonst gibt es kein Szenario und auch kein Zwang das so zu lösen. Bezüglich Printer-Sicherung: Da finde ich die beste Lösung der neue Druckservermanager von Vista/Server 2008 aufwärts. Damit kannst auch Konfigurationen von entfernen Server sichern (Alle Einstellungen + Treiber) und auf einem entfernten Server (also 2003) wieder einspielen.

@NeMix: Bei einem Datenverlust steht man grundsätzlich immer alleine da. Da nützt aller Support nix. Support hilft in der Regel nur um die Backups - sofern vorhanden - zurückzuspielen und die Hardware wieder zum laufen zu kriegen. ;) @LK: Lizenztechnisch dürfte es im Grunde kein Problem geben. Ich persönlich würde denoch eine Standardlizenz nehmen. Die ist dann wenigstens voll nutzbar, auch wenn mal was am Design geändert wird. Würde zwar auch eher auf nen zweiten ESXi setzen, aber die von Dir genannte Variante geht auch, wenn der Rest der Umgebung wirklich egal ist. Allerdings würde ich der Kiste wenigstens nen Hardware-RAID spendieren. Bei kleinen Umgebungen bitte immer alle Recovery-Szenarien auch auf Fremdsystem durchspielen. Ist zwar mit virtuellen Systemen in der Regel deutlich entspannter als früher, aber sinnvoll planen sollte man trotzdem.

Erwarte bessere 1. Performance, da HD-Köpfe weniger springen müssen (Fragmentierte Files, sowohl für das Log als auch die anderen Files die so automatisch fragmentiert werden) 2. Bessere, schnellere oder weniger Rechenintensives Dedupe, dabei dürften wenig fragmentierte Files auch eher vorteilhaft sein 3. Bessere Recovery-Voraussetzungen schaffen (versehentlich gelöschte Files z.B.) Vor allem bei letzterem habe ich die Erfahrung gemacht, dass dies deutlich einfacher ist mit einem defragmentierten System. Eine auf eine grosse Fläche verteiltes USN-Journal verhindert eine einfache und saubere Defragmentierung. Zudem ist die Defragmentierung deutlich zeitaufwendiger und braucht mehr Schreiboperation. Wenn das mit verhältnissmässig einfachem Aufwand möglich ist, dann wären diese Dinge quasi umsonst zu haben, ohne dass man irgendwas beachten muss.

Wie gesagt: Ziel wäre das Fragmentieren des USN-Journals zu verhindern bzw. sehr in Grenzen zu halten. Auf grösseren Volumes mit vielen Änderungen hatte ich da schon über 1000 Fragmente gesehen. Wenn nun das Journal tatsächlich effektiv rotierend in den selben Blöcken ist, könnte man es doch genügend gross anlegen und es bleibt dabei. Stören würde es auf alle Fälle nicht. Vielleicht gäbe es sogar ein kleiner Performance-Vorteil? Von daher würde es mich interessieren, was evtl. Wege wären, die zum Ziel führen könnten.

Hallo Leute, Kennt jemand eine Möglichkeit, mit welchem man ein USN-Journal vorfertigen könnte? Habe dazu irgendwie keine Flags gefunden. Ziel: Von Anfang an die unglaubliche Fragmentierung des USN-Journals verhindern. 1. Ich weiss nicht ob das USN-Journal wenn es voll ist, wieder in die gleichen Sektoren schreibt, einfach am Anfang 2. An und ausschalten für eine Neuerstellung hat zu viele Nebeneffekte die man beachten muss. (Datensicherung, Replikationen etc.) Jemand ne Idee oder sogar ein fertigs Script? Ein Ansatz, allerdings keine Ahnung ob und wie das klappt: Solange Files in einen hohen Bereich der Festplatte schreiben, bis die gewünschte Max-Grösse des Logs erreicht ist. Allerdings müsste man dazu mit der Windows API schreiben, welche wiederum irgendwo schreibt. Das heisst vor den Kopiervorgängen muss ein wenig Platz vorhanden sein durch eine Datei die man wieder rauskippt, die gleich gross oder gröser ist, wie die Menge um die das USN-Journal jeweils vergrössert wird oder zumindest kleiner als das File das man kopieren möchte. Nützt aber natürlich alles nur, wenn anschliessend die bestehenden Sektoren überschrieben werden. Über den Sinn oder Unsinn soll hier nicht diskutiert werden, sondern lediglich ob es technisch geht oder nicht. Falls es geht, wie es eben geht. Grüsse und vielen Dank für Inputs

Es kommt beim SBS ein wenig darauf an wie man IPv6 deaktiviert. Einfach nur das Protokoll ausschalten auf der Netzwerkkarte wird Probleme bereiten. Wie bei vielem, entweder zieht man es durch, oder man lässt es bleiben. Hier mal ein Auflistung der MS-Software / Funktionen die IPv6 bieten oder erfordern. Erfordern trifft eigentlich nur für Direct Access zu. Ansonsten: - IPv4 to 6 Converter Dienst deaktivieren (IP Hilfsdienst - iphlpsvc) - IPv4 to 6 Adapter deaktivieren (Nettes Script: http://www.ryanvictory.com/posts/automating-6to4-adapter-removal-in-windows/) - IPv4 to 6 Protokolle aus allen Netzwerkadapter entfernen Bei Technet: http://blogs.technet.com/b/sbs/archive/2011/02/18/small-business-server-2011-slow-to-boot-and-several-services-fail-to-start.aspx Wie immmer gilt: Sauber dokumentieren und eventuell auch entsprechende Rückgängig-Scripte vorbereiten. EDIT: Man sollte auch immer beachten MS 'erfordert' quasi IPv6 per Defintion. Allerdings können sie es nicht wirklich erfordern wenn die Hälfte aller externen und internen Dienste noch IPv4 voraussetzt. Man hat im Supportfall unter Umständen einen schwereren Stand.

Hi Daniel, Hat es etwas gedauert, aber so ganz unkommentiert kann ich das nicht lassen... In der Tat. Es gibt aktuell ne Menge zu klagen. Es ist meiner Meinung nach auch sachlich. Dennoch muss es erlaubt sein, dass man den Ärger ebenso raushört, wenn einem die Entwicklung einer sehr geschätzten Firma derart massiv missfällt. Ich habe nicht behauptet, dass diese Regelung früher fair war. Im Gegenteil. Ich fand es schon immer unfair, dass wenn eine Instanz lokal durch eine Remotetechnologie technisch unbrauchbar wurde, auf der Remoteseite die genau gleiche Office Version bezahlt werden musste. Das war einfach eine Regelung die Akzeptiert wurde oder die Leute schlicht und ergreifend unterlizenziert waren und das im Grunde auch MS wenig interessiert hat. Mit dem technischen Fortschritt sind die potentiellen Endgeräte in der Zahl heute aber deutlich gewachsen, die Kontrollmöglichkeiten auch. --> Die Kosten waren für einen kleineren Betrieb überschaubar zu halten, weil OEM-Versionen die gleiche Funktionalität boten wie die digitalen Lizenzen und sogar reimaged werden durften MS hat keinerlei Nachteil wenn ein Desktop Remote genutzt wird. Die lokale Instanz ist unbrauchbar. Nutzt man RDP oder eine davon Abhängige Fremdanbietersoftware, soll eben auch eine RDS-Lizenz bezahlt werden. Das ist nichts wie korrekt. Aber doch nicht nochmal Windows und Office. MS schafft hier keinerlei Mehrwert. Die Firma nutzt nur die Tatsache aus, das man keine Wahl hat. Wie gesagt, mich stört überhaupt nicht, dass man eine Instanz bezahlen muss. Mich stört, - dass es nicht mir überlassen ist wo ich die Instanz laufen lasse - ich für eine nutzbare Instanz mehrfach bezahlen muss oder dafür einen Wartungsvertrag brauche Würde SA so eingesetzt wie es eigentlich gedacht war, dann wären da Features mit drinn wie - ColdStandby - eine zweite laufende SQL-Instanz für Desasterszenarien, die nicht genutzt wird - eine zweite laufende Exchange-Instanz - Lernkram - Produkt Upgrades - Testlizenzen MS hat keinerlei Nachteil wenn ich eine VM von A nach B verschiebe. Ich nutze bei Verwendung von z.B. VmWare dazu weder eine bestimmte Technologie von MS noch mehr Funktionalität als ich eh schon habe. Also wozu ist dafür eine SA (Server Applikationen) oder eine Doppellizenzierung (Server) notwendig? --> Im Prinzip geht es doch nur darum, das Monopol auszunützen, SA aufzuwingen und aktuell grad lokale Installationen möglichst unattraktiv zu gestalten. Der zweite Grund ist die Ausschaltung von Mitbewerbern. Small Business Server 2003 CAL kam mit Outlook. Soweit ich mich erinnere ebenso Exhange 2003 CAL. Mit dem Wegfall unter Exchange 2007 habe ich/Kunden dank SA für jede CAL unter SA ein aktuelles Outlook bekommen. Soweit so fair. Heute oder für die Verlängerung brauch man: - Eine Standard CAL - Eine Enterprise CAL - (fast) zwingend Outlook oder Office - das ist noch nicht genug, deshalb noch SA für alles 1* Wie gesagt, ein Upgrade einer Software kauft man um mehr Funktionalität zu erhalten. Eine SA im Grunde um die neuesten Versionen sowie ein paar Goodies, nicht aber Funktionalität zu erhalten. Das dem heute nicht mehr so ist, ist mir auch klar. 1*) Es gibt wenige Ausnahmen wo nicht alles nötig ist, aber das ist die Idee die MS verfolgt und nach und nach durchsetzt Das ist mir schon klar. Aber wenn MS das erkannt hat, dass eine Produkt eben heute sinnvollerweise auch pro Person lizenziert wird, warum kann ich dann anstelle Office 365 nicht einfach ein OfficePro Plus für einen Mitarbeiter kaufen? Technisch ist es das gleiche. Lösung: MS will nur noch Miete verkaufen, weil dies der versachlichte Goldesel ist, der weniger Innovation erfordert. Egal ob ein MA 10 Geräte oder eines hat, er kann nur eines aufs mal benutzen. Vor allem wenn er noch auf die gleiche Instanz zugreift. MS hat sogar weniger Arbeit, weil ich den technischen Unterhalt mache. Aber MS wäre zu Innovation verpflichtet, sonst wird das neue Produkt nicht gekauft. Das war ihr grösstes Problem nach XP und Office 2003. Es kamen keine Innovationen welche die Masse wirklich wollte. Nützliche Innovationen wurden wiederum schlecht kommuniziert und klassisches in den Wind geschossen. Wie gesagt, personalisierte Werbung ist das kleinste Problem und läuft nur unter Kategorie lästig oder für manche sogar unter der Kategorie nützlich. Richtig mies ist hier vor allem das Missbrauchspotential welche solche Datensammlungen bieten. Das muss nicht offiziell von der Firma sein, dazu reichen eine Handvoll Mitarbeiter oder Sicherheitslecks aus. Deshalb möchte ich eine richtige Wahl haben, wie ich ein Produkt einsetze. In der Cloud oder daheim / in der Firma. Ebenso möchte ich ein Produkt kaufen können. Da ist man wenigstens nicht vollständig ausgeliefert und die Hersteller hat einen gewissen Innovationsdruck. Fällt mir durchaus schwer. Wahnsinnig spassig finde ich das ehrlich gesagt nicht :rolleyes:

@Dr. Melzer: Nein, ich verwechsle da leider gar nichts. Ich sage ned mal was anderes wie Du, siehe Lösung Notebook. 1. Remote Session irgendwelcher Art = das zugreifende Gerät muss OS + Office Lizenz haben (Einzige Ausnahme: Hauptbenutzer, den es nie gibt wenn X-Leute einen PC benutzen) 2. Können nun also mehrere Mitarbeiter Remote auf diese Instanz zugreifen, dann sind pro Benutzer unter Umständen sogar mehrere Lizenzen fähig. Das heisst im Extremfall (der heute gar nicht so unwahrscheinlich ist): 1. für das Gerät selber, die 2. für das Smartphone jedes Benutzers, die 3. für das Tablet jedes Benutzers, die 4. für den Home PC jedes Benutzers. Das wirklich interessante ist aber, dass der PC dann weder lokal, noch mit einer anderen Remote-Session benutzt werden kann, weil MS das softwaretechnisch unterbindet. Streng genommen müsste man X-Lizenzen bezahlen und nutzen kann man doch nur eine Instanz aufs mal. Das ist was zumindest was bei genauer Auslegung der PUR's gefordert wäre. Natürlich bleibt es wiederum jedem frei, jedem MA einen eigenen PC hinzustellen damit es einen Hauptbenutzer gibt. Es gibt zudem keine Passage die besagt, dass es ausreichen würde, wenn jeder Mitarbeiter eine Office-Lizenz hat, dafür darf Office überall genutzt werden. Das geht nur mit Office 365. Das heisst also: Die einzige Möglichkeit Windows und ein Office oder eine Applikation wie Visio wirklich sinnvoll mobil für jeden zu halten ist wie gesagt ein Notebook.