NilsK

Moin, gut, mittlerweile hat jeder seine Haltung zu der Lizenzfrage kundgetan. Ursprünglich war es ja nur als mögliches Problem erwähnt worden. Der Kernpunkt ist doch, dass der TO offenbar gar kein Abschalten braucht, sondern ein Management. Dass seine Bedenken berechtigt sind, steht außer Frage. Dass Microsoft sich bezüglich der Steuerbarkeit von Updates und Upgrades derzeit nicht mit Ruhm bekleckert, ist ebenso offensichtlich. Ändert aber nichts daran, dass Steuern besser ist als Ignorieren. Gruß, Nils

Moin, schon mal über Office 365 nachgedacht? Gerade in so kleinen Umgebungen ist das mittlerweile eine ernsthafte Alternative. Den lokalen Server kannst du dann viel einfacher halten, vielleicht sogar ganz darauf verzichten. Gruß, Nils

Moin, man bekommt den Host nicht geschenkt, sondern man hat ihn lizenziert. Sobald man zwei Windows-Server-VMs darauf laufen lässt, sind die Lizenzrechte der Standard-Lizenz ausgeschöpft. Auf dem Host darf man dann nichts mehr betreiben, was für das VM-Hosting und das Host- und VM-Management nicht nötig ist. Die Dienste, die du aufführst, fallen genau darunter. Du darfst sie also ohne eine zusätzliche Lizenz auf dem Host betreiben. Gruß, Nils

Moin, du kannst ein Skript bauen, das dir den Link aus der XML-Datei extrahiert und diesen dann per Kommandozeilenaufruf an dein PDF-Programm zum Drucken weitergeben. Für den Acrobat Reader findest du die nötigen Schalter schnell über eine Websuche. Was das Extrahieren des Links angeht, wäre es am sichersten, die XML-Datei "richtig" zu parsen. Damit bist du am ehesten auf der sicheren Seite, wenn sich die Struktur des Dokuments mal ändert. Du kannst auch mit einfachen String-Operationen arbeiten und den Beginn und das Ende des Links identifizieren und alles vorher und nachher entfernen - das schlägt aber evtl. fehl, wenn der Aufbau der Datei sich mal ändert. In der PowerShell käme etwa das Cmdlet Select-Xml in Betracht. Gruß, Nils

Moin, vielen Dank, Franz, für die Hinweise! Der Nano-Server ist aus verschiedenen Gründen nur für sehr spezielle Szenarien geeignet. Zwar positioniert ihn Microsoft auch für diverse "herkömmliche" Einsatzzwecke (z.B. könnte man ihn auch als Hyper-V-Host einsetzen), aber faktisch dürfte er nur als Basis-OS für Container in Frage kommen (also die neue Technik für Web-Applikationen, Stichwort "Docker"). Zu den (absichtlichen) technischen Beschränkungen (es ist eben ein Minimal-OS) und den Lizenzthemen kommt ja auch noch, dass der Nano-Server dem CBB-Aktualisierungsmodell unterliegt: Man muss ihn alle paar Monate upgraden, wenn ein neuer Build herauskommt. Damit eignet sich Nano nur für kurzlebige Systeme - eben hauptsächlich Container. Gruß, Nils

Moin, vielleicht darf ich noch mal darauf hinweisen, dass du gar keine AD-Migration durchführen willst. Du machst ein Domänen-Update, indem du der bestehenden Domäne einen neuen DC mit einem aktuelleren Betriebssystem hinzufügst. Wenn man nicht mutwillig etwas anstellt, ist das praktisch ohne Risiko. Bei Exchange kann man von einer Migration sprechen, aber auch da ist der Vorgang eigentlich derselbe - weswegen man es eben auch als Update bezeichnen kann. Neue Version von Exchange in die bestehende Umgebung (Alt und Neu kennen einander), Mailboxen verschieben, Verbindungen anpassen. Fertig. Ebenfalls praktisch ohne Risiko, vielleicht gibt es zwei, drei (korrigierbare) Stolperstellen. Bitte nicht aus lauter Unwissenheit einen nicht unterstützten Weg gehen, den am Ende niemand mehr korrigiert bekommt. Es ist ja nicht so, dass die empfohlenen Verfahren nicht dokumentiert wären. Gruß, Nils PS: Ich mach hier mal Schluss, viel Erfolg und Vergnügen noch.

Moin, das ändert nichts daran, dass wir in diesem Board keine Lizenzverstöße supporten. Den Hinweis auf eine Regel, die du bei der Anmeldung ausdrücklich akzeptiert hast, bitte künftig berücksichtigen und nicht mit irgendwelchen Spitzfindigkeiten abtun. Danke. Nils

Moin, ja, es ist ein Trauerspiel ... in den ersten TPs hat Microsoft noch einen gegenteiligen Plan verfolgt: Es sollte nur Core und MinShell geben. Danach sollte es zwar das volle GUI wieder als Option geben, aber MinShell sollte Standard sein. Nun hat man sich von MinShell ganz verabschiedet. Lustig ist dabei ja auch, dass einige vorinstallierte Dienste, die nur auf einem Client Sinn ergeben, auf dem Server Fehler verursachen. Daher kursieren auch schon die ersten Anleitungen, welche Dienste man manuell deaktivieren sollte ... erinnert irgendwie an Windows 2000. Vermutlich wiederholt sich die Geschichte, und in drei Jahren verkündet Satya Nadella eine neue Strategie namens "Trustworthy Computing". Dann werden alle Entwicklungen angehalten und die Designer und Entwickler erst mal unterwiesen, wie man sicheren Code baut ... Gruß, Nils

Moin, falls es nicht am Virenscanner liegt, würde ich die Hardware in den Kreis der Verdächtigen nehmen. Gruß, Nils

Moin, cool, danke für den Hinweis! Gruß, Nils

Moin, dann wirst du das Problem beim nächsten Mal wieder haben. Vielleicht findest du es ja dann. ;) Da das "Problem" aber eigentlich auch kein solches ist, ist das in dem Fall schon okay. Gruß, Nils

Moin, das schrob er schon: http://www.mcseboard.de/topic/208817-telnet-verbindungsherstellung-extrem-langsam-bei-windows-20122012r2/?do=findComment&comment=1317631 Gruß, Nils

Moin, hm, klingt noch spannender! ;) Da würde mich dann hinterher mal die Auflösung interessieren, falls ihr eine findet. Gruß, Nils

Moin, aber wenn du den CN haben willst, warum nimmst du dann nicht einfach gleich das dafür zuständige Feld? Dann brauchst du hinterher nicht rumzubasteln. Gruß, Nils

Moin, na, dann viel Erfolg ... Wenn es dir nur um die Datensicherung geht (und nicht um parallelen Zugriff, wie ich erst annahm), würde ich aber den Aufwand mit DFS (und seine vielen, vielen Fehlerquellen) vermeiden und einfach einen Copyjob mit robocopy bauen. Da hat man dann auch Logs, kann bei Fehlschlägen automatisch wiederholen, kann die Bandbreite einschränken usw. Gruß, Nils

Moin, die kurze Antwort ist: vergiss es. Die bessere Variante ist in solchen Szenarien, die Anwender zu den Daten zu holen: Zugriff per RDP auf die Daten und Applikationen des Hauptstandorts. Jede Replikationslösung erzeugt i.d.R. so viele Folgeprobleme, dass man sehr schnell damit unzufrieden ist. Beispiel: Wenn dein Abteilungslaufwerk nur einmal täglich repliziert wird, die User aber an ihrem jeweiligen Standort arbeiten, wirst du ständig Replikationskonflikte und Datenverluste haben ("Last Writer Wins"). Gruß, Niös

Moin, hm, komisch. Gilt das nur für den Verbindungsaufbau, oder ist dann die ganze Session langsam? Gruß, Nils

Moin, "Assassin", nichts für ungut, aber zum Vermitteln von Grundlagen oder tiefsten technischen Details ist ein Forum nicht geeignet. Für das, was du vorhast, gibt es ein Standardverfahren, das seit 17 Jahren bewährt ist. Das Verfahren, das du skizziert hast, ist nicht geeignet. Eine Diskussion, welche technischen Abläufe in dem nicht geeigneten Verfahren eventuell oder auch nicht und vielleicht dann doch - führt zu gar nichts. Sie kostet nur Zeit. das Verfahren nennt sich "Replicate from media" und ist auch nur genau für diesen einen Sonderfall gedacht. Mit Migrationen oder Domänenupdates hat es nichts zu tun. Gruß, Nils

Moin, eine Idee habe ich nicht, aber hast du schon geprüft, ob es mit puTTY auch so lange dauert? Gruß, Nils

Moin, wird das hier ein Jehova-Wettbewerb? ;) Ich sage nur: USN Rollback und Lingering Objects. Das einzige, was mit Sicherheit funktioniert, ist das Erzeugen von vermeidbaren Schäden. Der wichtige Satz ist der mit der Shift-Taste. :D Gruß, Nils

Moin, naja, das kommt schon mal vor. Bei vielen Projekten weiß man ja nicht, wie die sich entwickeln. Aber wenn es dann eben auch um Performancefragen geht, dann braucht man in solchen Phasen eine gute Überwachung und sinnvolle Grundeinstellungen. Gruß, Nils

Moin, generell ist prozentuale Vergrößerung bei Autogrow schwierig. Wenn die Datei z.B. schon 500 GB erreicht hat, müssen bei 10 Prozent mal eben 50 GB alloziert werden. Bei kleineren Dateien hingegen führt das zu ständigen kleinen Häppchen und sorgt so für Fragmentierung. Als Faustregel empfehle ich daher immer große, feste Inkremente und ein Monitoring. Das ist aber Sache des Detaildesigns, genau wie die Nutzung von Filegroups. Gruß, Nils

Moin, ihr wollt nicht migrieren, sondern eure Domäne aktualisieren. Windows Server 2016 installieren, in die Domäne aufnehmen, zum zusätzlichen DC der Domäne hochstufen. Schema-Upgrade usw. läuft von selbst, Replikation sowieso. Clients bekommen nichts mit. Risiko praktisch Null. Deinen bisherigen Plan wirfst du bitte in den Papierkorb. Nur einen DC zu haben, ist in einer Umgebung mit mehr als 10 Arbeitsplätzen grob fahrlässig. Gruß, Nils

Moin, SQL Server füllt die Dateien, die zur selben Filegroup gehören, proportional zu dem freien Platz innerhalb der Datei. Möglicherweise führt das zu einer "Verzerrung" gegenüber deiner Erwartung, dass die Daten gleich verteilt seien. Zusätzlich kann das Autogrow hier zu einer nicht erwarteten Verteilung führen - Autogrow ist ohnehin in vielen Umgebungen problematisch, weil falsch oder ungünstig konfiguriert. Wenn man eine bestimmte Verteilung erreichen möchte, muss man die Parameter Größe und Autogrow also gemeinsam planen. https://technet.microsoft.com/en-us/library/ms187087(v=sql.105).aspx Gruß, Nils

Moin, was genau da auf dem Client schiefläuft, kann ich nicht sagen. Ganz sicher kann ich aber sagen, dass es nichts mit dem User im AD zu tun hat. Den solltest du also tunlichst nicht löschen, weil das an dem Problem nichts ändern wird, dafür aber viele neue erzeugt. Gruß, Nils