NilsK

Moin, das heißt, es geht jetzt? Falls nicht, ist die Lage leider diffus. Ich würde dann erst mal mit allgemeinen Dingen weitermachen - Updates und Treiber prüfen, Netzwerkkommunikation Ende zu Ende prüfen usw. Gruß, Nils

Moin, wenn es nur um identifizierbare Einstellungen geht und nicht um das ganze Profil, behelfe ich mir manchmal damit, diese in einen Cloudspeicher (oder an andere zentrale Stelle) zu kopieren. Ist nicht elegant, aber vermeidet die Probleme von Roaming Profiles und reicht oft aus. So mache ich es z.B. mit den Autokorrektur-Wörterbüchern von Office, die ich nur selten aktualisiere. Gruß, Nils

Moin, schau noch mal im Eventviewer unter den Dienstprotokollen für AD und DNS. Gruß, Nils

Moin, sagen wir es so: Das Vererbungssystem ist nicht eben die beste Seite von NTFS. Workflows der Art, wie du sie beschreibst, laufen immer wieder auf Probleme. Wenn es wichtig ist, sollte man daher nach anderen Lösungsansätzen suchen. Gruß, Nils

Moin, wo hast du den Forwarder eingetragen? Wenn ich nicht ganz falsch liege (kann gerade nicht nachsehen), kann man den pro Server eintragen. Wenn DC2 diesen Eintrag nicht hat, dann gibt es auch kein Forwarding. Ist die DNS-Zone AD-integriert? Ist sie korrekt repliziert? Gibt es weitere Fehlermeldungen in dem Zusammenhang? Gruß, Nils

Moin, gut, aber heute werden solche Szenarien ja meist mit Notebooks gelöst. Wie oft passiert das? Muss man dann eben abwägen, ob man sich dadurch das Gehassel mit Roaming Profiles antun will. Gruß, Nils

Moin, oh. Oh ja, du hast Recht. Gruß, Nils

Moin, zunächst wäre zu klären, ob ihr überhaupt Roaming Profiles braucht - und wenn ja, wozu. Viele setzen das nur ein, "weil es geht", aber in Wirklichkeit haben sie keine oder kaum User, die den Arbeitsplatz wechseln und überhaupt so einen Abgleich brauchen könnten. Gruß, Nils

Moin, naja, aber irgendwie muss der User ja schreiben können, nicht? Abgesehen davon, bewirkt der Regkey meinem Verständnis nach aber auch das Gegenteil von dem, was du suchst. Er sorgt dafür, dass die Originalberechtigungen der Datei erhalten bleiben, auch wenn du sie auf ein anderes Volume verschiebst ... Gruß, Nils

Moin, man könnte jetzt auch noch philosophieren, dass Hyper-V diesen Quatsch mit "vCores" gar nicht kennt, weil dieser Quatsch technisch ohnehin ohne Bedeutung ist (und am Ende, sagen böse Zungen, nur erfunden wurde, um Lizenzbestimmungen zu umgehen, was mittlerweile aber nicht mehr geht, weil die Lizenzgeber ja auch nicht auf dem Baum schlafen). Gruß, Nils PS. Und ja, ich bin auch der Meinung, dass Leute, die sich Lizenzbedingungen ausdenken, einen offenkundigen Mangel an innerer Erlebnisbereitschaft haben. Nähmen sie stattdessen Drogen, wäre der volkswirtschaftliche Schaden vielleicht sogar geringer.

Moin, kläre und definiere die Anforderungen genauer, nur dann kannst du ein passendes Konstrukt entwerfen. "Ausfallsicher" ist sehr dehnbar. Ebenso ist "nur eine Seite" sehr schwammig - "Portal" heißt üblicherweise eben sehr wohl, dass da eine Datenbank und einiges an Logik dahinter ist. Gruß, Nils

Moin, nicht "der Clusterring", sondern "Clustering". Der Datenbankserver ist in solchen Setups typischerweise ein Cluster aus zwei oder mehr Servern, die die Datenbank hochverfügbar halten. Sonst hätte man bei einem Ausfall des Datenbankservers gleich einen Ausfall des Gesamtsystems der Applikation. Muss man nicht so machen, wäre aber ein typischer Aufbau. Sind die Anforderungen geringer, reicht auch ein einzelner Datenbankserver. Wie man das konkret baut, hängt von der verwendeten Datenbank ab. Gruß, Nils

Moin, Webserver hält man i.d.R. über einen vorgeschalteten Load Balancer hochverfügbar. Mit Windows-Bordmitteln bekommt man sowas nicht zufriedenstellend hin. Da gibt es kommerzielle Lösungen oder Open-Source-Produkte. Den Datenabgleich zwischen den eigentlichen Webservern muss man dann selbst lösen. Meist funktioniert es so, dass die eigentliche Web-Applikation "statuslos" ist, d.h. es ist dort nur die Anwendungslogik auf allen Servern identisch hinterlegt. Die Datenhaltung geschieht dann in einer separaten Datenbank, die man ihrerseits meist über Clustering hochverfügbar hält. So ist kein Abgleich zwischen den Webservern nötig. Nur Änderungen an der Applikation (z.B. Updates) muss man dann auf allen Webservern identisch ausführen. Gruß, Nils

Moin, bei Exchange 2010 war die Lizenzmobilität auch noch in der Grundlizenz enthalten (bzw. das Konztept gab es zum Release noch gar nicht). Erst seit Version 2013 benötigt man die SA für vMotion, Live Migration usw. Beim SQL Server war Microsoft schon ein Jahr früher auf die Idee gekommen, da galt das ab Version 2012. Gruß, Nils

Moin, z.B. hier ab Minute 29:49: https://channel9.msdn.com/Events/community-germany/VCNRW2016/Hyper-V-Mythen-und-Wahrheiten Gruß, Nils

Moin, was natürlich nur funktioniert, wenn die Daten in mehreren "Streams" kommen. Sonst ist da nichts zu parallelisieren und die zweite Karte bringt keine Beschleunigung. Was keine gute Idee ist. Da hättest du von der Virtualisierung schon den Nutzen, dass du diese Rollen künftig trennen kannst. Gruß. Nils

Moin, der Host braucht natürlich Ressourcen, aber er "belegt" nicht dauerhaft zwei Cores. Du weist "dem Hostbetriebssystem" auch keine Cores zu. Im Allgemeinen ist der Overhead so gering, dass man ihn nicht mal messen kann. Und es passiert auch sehr selten, dass eine Applikation wirklich alle Host-Ressourcen bräuchte - ich habe sowas noch nie gesehen. Solltest du einen dieser sehr seltenen Fälle haben und der Grund ist nicht, dass die Software so schlecht programmiert ist, dann hättest du wahrscheinlich einen der seltenen Fälle, in denen Virtualisierung nicht das richtige wäre. Gruß, Nils

Moin, in solchen Fällen ist ein Gespräch mit dem Vorgesetzten immer die beste Wahl. Solche Fragen bewegen sich schnell im Graubereich des Geregelten - da kann man zwar auf einer Rechtsgrundlage beharren, aber ob die wirklich zutrifft, ist am Ende von Laien nicht zu beurteilen. Eine beidseitige Absprache ist daher i.d.R. vorzuziehen. Gruß, Nils

Moin, wieso muss ein "Durchschnittsuser" Software installieren? Wenn so ein User Zugriff auf ein Adminkonto hat, kann man alles Weitere eigentlich auch vergessen. Gruß, Nils

Moin, ach so ... das war wirklich missverständlich formuliert. Ich hatte gedacht, es gehe um AD-Accounts pro System, die lokal berechtigt sind. Genau das wäre auch der Schlüssel zur Lösung: Erzeuge je System einen Admin-Account im AD, der lokaler Admin wird. Dann kannst du solche Berechtigungen gut verteilen. Die lokalen Konten entfernst du von den Systemen. Lokale Konten haben halt nur lokale Rechte und können im Netzwerk nichts. Gruß, Nils

Moin, eine Gruppe für diese Admin-Accounts? Gruß, Nils

Moin, um nicht zu sagen: Die Antwort auf deine Frage "Ist es möglich ..." lautet "Nein". Die Antwort auf die Frage nach den Konsequenzen lautet "Ja". Wozu brauchst du denn die Zuordnung? Gruß, Nils

Moin, ob das sinnvoll ist, kannst du nur selbst anhand deiner eigenen Zukunftspläne beurteilen. Vielleicht bietet sich ergänzend eine Studienberatung an. Ein Studium bewegt sich auf einer ganz anderen Ebene als eine Herstellerzertifizierung. Gruß, Nils

Moin, in einem Thread, den du selbst eröffnet hast, findest du in allen Beiträgen von anderen Leuten links neben dem Namen ein graues Häkchen-Feld. Damit kannst du den Beitrag markieren, der die Lösung erbracht hat. Gruß, Nils

don't feed the trolls