NilsK

Moin, ich habe von Microsoft über den Partnerkanal eine Information erhalten, die hoffentlich zutrifft. Demnach ist das Free Upgrade Offer (bis Ende Juli 2016) für Unternehmenskunden nicht eingeschränkt. Einzig die Enterprise-Versionen von Windows 7 und Windows 8.1 (sowie als Spezialfälle die Embedded-Versionen und Windows RT) sind nicht kostenlos upgradefähig. Kunden mit Volumenlizenzen (Win7, Win8.1) können das Free Upgrade Offer wahrnehmen und damit "kostenlos" aktualisieren. Obacht aber: In dem Fall wird aus der vorhandenen Volume-Lizenz eine "normale" Gerätelizenz, die keinen Volume-Charakter hat, nicht im VLSC auftaucht und auch nicht zur Nutzung von evtl. vorhandenen Volume-Tools berechtigt. Das Zitat stammt aus einem Dokument namens "320704740-0-Windows10-UpgradeCommercialCustomerOptions.docx", von dem ich leider nicht weiß, ob ich es weitergeben darf. Wer die Vorteile der Volume-Lizenzen (Support, Tools usw.) weiter nutzen will, muss eine neue Windows-10-Volume-Lizenz kaufen. (Dabei ist immer zu berücksichtigen, dass Volume-Lizenzen stets Upgrade-Lizenzen sind, man darf sie also nicht auf einen "nackten", unlizenzierten PC installieren, sondern sie sind dazu gedacht, die Volume-Vorteile zu einer bereits vorhandenen Lizenz hinzuzufügen.) Gruß, Nils

Moin, LTSB ist auch teurer, oder? Abgesehen davon, hat es einige technische Einschränkungen. Ich würde also eher nicht darauf setzen. Wenn die SA ausläuft, darf man Enterprise nicht mehr nutzen, unabhängig von der Geschmacksrichtung. Man müsste dann mit Pro neu installieren. Gruß, Nils

Moin, "Ausfallsicherheit" ist keine Anforderung. Das ist, wie du schon richtig sagst, laienhaft. Okay für einen Nicht-Fachmann, aber deshalb noch lange nicht ausreichend. Ein kleines Unternehmen braucht sicher keine tagelange Analyse, aber sie braucht sehr wohl mehr als ein Schlagwort. Auf dem, was hier bislang an "Anforderungen" geäußert wurde, technische Anleitungen zu gründen, halte ich für grob fahrlässig. Daran beteilige ich mich nicht. Gruß, Nils

Moin, also, da hier offenbar eine Abneigung gegen die richtige Reihenfolge herrscht (erst Anforderungen klären, dann Machbarkeit prüfen, dann umsetzen), bin ich raus aus diesem Thread. Gruß, Nils

Moin, gerade wenn du der einzige bist, der das betreut, solltest du dir jemanden dazuholen, der sich mit sowas auskennt. Das ist dir jetzt schon mehrfach empfohlen worden. Erfahrungsgemäß ist das auch schnell deutlich günstiger als es selbst zu versuchen und nach wenigen Wochen irgendwo vor die Wand zu fahren und Daten und viel Zeit zu verlieren. Gruß, Nils

Moin, noch besser ist es, du lässt dich von jemandem mit Erfahrung und konkreten Fachkenntnissen über Ausfallsicherheit und Datensicherung beraten. Gruß, Nils

Moin, hinter den Kulissen wird "Konto läuft nie ab" auch tatsächlich über einen "***isch hohen" Wert im Attribut AccountExpires geregelt (Hex 7fff und ganz viele f dahinter; das ist 2 hoch 63 minus 1)*. Daher würde ich da keinen eigenen "***isch hohen" Wert setzen, sondern die betreffenden Accounts eben auf "läuft nie ab" setzen. https://msdn.microsoft.com/en-us/library/windows/desktop/ms675098%28v=vs.85%29.aspx Gruß, Nils * tatsächlich ist es noch etwas komplizierter, der Wert kann auch 0 sein. Näheres dazu findet sich hier: http://www.rlmueller.net/AccountExpires.htm Dort steht auch das theoretische Enddatum der Zeitskala: 14. September 30.828

Moin, das Zertifikat selbst ist ja nicht abgelaufen, sondern das vorgelagerte Zertifikat des Ausstellers. Dieses vorgelagerte Zertifikat muss also erneuert oder verlängert werden. Danach muss man es den Clients zur Verfügung stellen. Ein typischer Designfehler: Die Laufzeiten der Zertifikate sind nicht aufeinander abgestimmt. Dabei ist die Laufzeit des End-Zertifikats mit fast 27 Jahren auch unsinnig lange. Möglicherweise solltet ihr euch dazu mal Beratung holen. Gruß, Nils

Moin, du kannst ein Server-Betriebssystem nicht "auf" Windows 10 installieren. Du kannst es nur statt des ursprünglichen Betriebssystems installieren, d.h. Windows 10 würde dabei ersetzt. Allenfalls wäre eine "Dual Boot"-Installation möglich, bei der beide Systeme parallel auf der Platte installiert sind, du wählst dann beim Starten des Computers aus, welches System laufen soll. Bei einer solchen Neuinstallation spielt die Sprache keine Rolle. Gruß, Nils

Moin, verrätst du uns auch, welche Schalter dein Kommando momentan nutzt? Gruß, Nils

Moin, 2016 würde ich kurzfristig nur nehmen, wenn die geplante Backup-Lösung (sowie weitere Zusatzprodukte, z.B. Antivirus) es ausdrücklich unterstützt. Manche sind da noch nicht so weit und brauchen noch ein paar Wochen. Eine neue Umgebung würde ich jetzt nicht mehr mit 2010 einrichten, wenn es keine wichtigen Gründe dafür gibt. Gruß, Nils

Moin, sehe ich auch so. Schon aus Gründen der Datenhygiene - wenn es kein definiertes Datum gibt und man keins eintragen muss, dann trage man keins ein. Dummy-Daten fallen einem früher oder später auf die Füße. Insbesondere die Frage nach Beginn und Ende der Zeitskala lässt sich auch nicht eindeutig beantworten, das hängt immer sehr davon ab, welche Programmiersprache, welche Schnittstellen, welche Funktionen usw. betroffen sind. Excel sieht das etwa völlig anders als C#. Gruß, Nils

Moin, in diesem Dokument sind die bekannten Limits aufgeführt: [Wie viel [XYZ] kann Active Directory speichern? | faq-o-matic.net] http://www.faq-o-matic.net/2009/02/20/wie-viel-xyz-kann-active-directory-speichern/ Ob es für die Datumsfelder ein definiertes Limit gibt ... nie gehört. Ich denke, alles was in "normaler" Zukunft liegt und nicht im Hintergrund irgendwelche Formate sprengt, dürfte unkritisch sein. Dabei dürfte es aber weniger auf das AD als Datenbank ankommen als vielmehr auf die Programme oder Komponenten, die das Feld dann auswerten. Was ist denn der Hintergrund der Frage? Gruß, Nils

Moin, dass das "Overkill" sei, stelle ich in Abrede. Wenn das so ist, gibt es keine Anforderung an Hochverfügbarkeit. Zu dem Konstrukt ist hier schon ausreichend gesagt worden. Wenn man es ordentlich macht, kann es einfache Hardware-Ausfälle so überbrücken, dass man nur geringe Ausfallzeiten hat. Man mache sich aber nichts vor: Eine empfindliche fünfstellige Summe wird es immer kosten, und dabei gibt es dann noch viele Szenarien, die eben doch lange Ausfallzeiten bedeuten können. Damit wären wir dann wieder bei den Anforderungen ... Auch zu den Lizenzen ist das Wichtigste gesagt. Zwei Hosts mit je einer Standard-Lizenz reichen für zwei geclusterte VMs aus. Für Exchange braucht es dann noch SA, damit die VM den Host wechseln darf ("License Mobility"). Gruß, Nils

Moin, ein einfaches "tut mir Leid" hätte völlig ausgereicht. Es wäre nicht nötig gewesen, noch weitere Beleidigungen anzufügen. Für mich endet der Support an dieser Stelle. Gruß, Nils

Moin, für das bislang diskutierte Szenario hat vSphere exakt null Vorteile. Dafür den Nachteil von vierstelligen Euro-Summen als Zusatzkosten. Man braucht bei Aufbau mit Hyper-V nicht zwingend einen separaten DC. Es ist trotzdem zu empfehlen, und das gilt mit vSphere exakt genauso - nicht wegen des Clusters (der startet seit Windows 2012 auch ohne erreichbaren DC), sondern wegen der allgemeinen Abhängigkeit der Infrastruktur von AD. Ein Recovery geht meist erheblich schneller, wenn man sich nicht erst um das AD kümmern muss, weil es auf dem physischen DC bereits läuft. Exchange und DC auf derselben Server-Instanz ist ein No-go. POP-Connectoren sind das heute auch. "Verfügbarkeitslösungen", die auf Batches beruhen, sind niedlich, manchmal auch pfiffig, aber in den meisten Situationen kaum ernst zu nehmen. Und im Übrigen wird hier wieder mal das Pferd von der falschen Seite aufgezäumt: Zuerst wäre zu klären, was denn überhaupt die Anforderungen sind. EIn Wort wie "ausfallsicher" reicht da bei Weitem nicht aus. Gruß, Nils

Moin, das kann man steuern. Ein üblicher Weg ist, solche internen Zertifikate einfach "auslaufen" zu lassen. Das setzt voraus, dass mindestens ein CRL-Pfad, der im Zertifikat benannt ist, erreichbar ist, bis das letzte Zertifikat abläuft oder nicht mehr genutzt wird. Dazu braucht man nicht die ganze CA, sondern nur den Web- oder Dateipfad. Gruß, Nils

Moin, wie ist denn nun der Zustand? Leider ist deine Beschreibung nicht ganz verständlich. Der alte DC läuft noch? Dann hast du kein ernstes Problem. Im Zweifel überträgst du die FSMO-Rollen zurück (dauert 5 Minuten), entfernst die "Reste" der zusätzlichen DCs aus dem AD (= Löschen im AD-Verwaltungsprogramm und in DNS) und richtest neue ein. Ach so, du machst übrigens keine Migration, sondern nur eine Aktualisierung. Das ist ein Unterschied. Niemals parallel zu Hyper-V weitere Rollen installieren, die nötigen Links wurden dir bereits genannt. Gruß, Nils

Moin, Sven, du vergreifst dich im Ton. Der Hinweis von Sunny ist insgesamt richtig. Allerdings ist das Abschalten von UAC nur dann eine Gefährdung, wenn Anwender über Adminrechte verfügen, denn in dem Fall werden sie eben nicht mehr geschützt. Sind die Anwender normale User, dann macht das Abschalten der UAC keinen Unterschied. Der Hinweis des Herstellers deutet also eher darauf hin, dass er selbst das Konzept nicht versteht. Hast du denn nun mal geprüft, ob sich das Programm ohne Adminrechte ausführen lässt? Wenn du das nicht prüfst, können wir uns die Diskussion hier sparen. Gruß, Nils

Moin, melde dich als normaler User an und starte das Programm. Kommt ein UAC-Aufruf? Dann ist Windows der Meinung, dass das Programm Adminrechte braucht. Kommt keiner, und das Programm läuft? Dann braucht es keine. Das UAC-Icon blendet Windows manchmal bei Altsoftware ein. Das heißt aber nicht unbedingt, dass das Programm Adminrechte braucht. Also lieber testen statt nur zu vermuten. Gruß, Nils

Moin, das Verstecken der Freigaben oder der Rechner löst doch aber das Problem nicht. Wenn überhaupt, dann muss man das per Berechtigung ändern. Gruß, Nils

Moin, als Quick-and-Dirty-Variante könntest du bcp.exe nehmen. https://technet.microsoft.com/en-us/library/ms189569%28v=sql.105%29.aspx Gruß, Nils

Moin, ergänzend zu Sunny solltest du im Blick behalten, dass auch die c't-Lösung "MachMichAdmin" (die nebenbei bemerkt immer noch funktionieren sollte) faktisch den User zum Administrator macht. Es startet ein CMD-Fenster, in dem der User Adminrechte hat. Von da aus kann er tun, was er will. Eigentlich ist das Skript ein Vorläufer der UAC, wobei UAC dann in den meisten Situationen noch die bessere Wahl wäre. Also: Nicht den User zum Admin machen, sondern das Programm als User lauffähig machen. Gelingt fast immer. Gruß, Nils

Moin, definiere "ohne Probleme". Gruß, Nils

Moin, nein, das hat der Server bestimmt nicht getan. Es gibt keine automatischen Reparaturen des AD. Auch im Modus "Verzeichnisdienstwiederherstellung" geschieht nichts von selbst, das ist nur ein abgesicherter Modus, in dem man manuell Reparaturen usw. ausführen kann. Möglicherweise gibt das Eventlog Auskunft darüber, was hier los war. Jedenfalls würde ich das System erst mal im Auge behalten und besonderen Wert auf das Backup legen. Gruß, Nils