Jump to content

NilsK

Expert Member
  • Gesamte Inhalte

    12.997
  • Registriert seit

  • Letzter Besuch

Reputation in der Community

559 Exzellent

5 Benutzer folgen diesem Benutzer

Über NilsK

  • Rang
    Expert Member
  • Geburtstag 07.08.1970

Webseite

Letzte Besucher des Profils

2.130 Profilaufrufe
  1. Server spiegeln samt Betriebssystem

    Moin, VMware FT hat eine ganze Reihe von Einschränkungen und setzt eine aufwändige Infrastruktur voraus. Ohne die Anforderungen näher definiert zu haben, würde ich das nicht in Erwägung ziehen. Abgesehen davon handelt es sich um exotische Technik, die in Wirklichkeit sehr selten eingesetzt wird. Ich rate dem TO, zunächst die Anforderungen zu definieren, sonst haben technische Empfehlungen wenig Sinn. Gruß, Nils
  2. AD-Gruppenmitglieder an Datenbank berechtigen

    Moin, dazu fällt mir aus der Ferne leider auch nichts mehr ein. Gruß, Nils
  3. Server spiegeln samt Betriebssystem

    Moin, also hat die Gesamtumgebung 10 Anwender? Oder sind es insgesamt mehr? Eine Image-Lösung wirst du nur schwer automatisieren können, zudem ist sie sehr hardwareabhängig. In der Praxis wird dir ein veraltetes Image wenig bringen, ebenso die relativ lange Zeit (und das Risiko) für die Wiederherstellung. Daher würde ich so ein "Spiegel"-Konzept niemals auf Hardware-Basis machen. Wenn überhaupt, dann per VM und Replikation, das beseitigt beide Einschränkungen. Ja, das würde bedeuten, die Umgebung auf virtuelle Maschinen umzustellen. In einer 10-User-Umgebung könnte man darüber diskutieren, aber allgemein ist auch von "Mischservern" abzuraten. Je mehr Applikationen, desto höher die Fehlerwahrscheinlichkeit und vor allem die Auswirkungen bei einem Fehler. Schon in kleineren Umgebungen würde man daher dazu neigen, Funktionen auf mehrere VMs zu verteilen. Im Fall der Virtualisierung kannst du mit einer einzigen Standard-Lizenz auf einem Host schon zwei VMs betreiben und damit wenigstens eine grundlegende Aufteilung erreichen. Wichtig: Jedes Image- oder Replikationsverfahren funktioniert nur, wenn die Applikationen das vertragen, sie dürfen dabei keine Inkonsistenzen im Datenbestand erzeugen. Meist ist das gegeben, aber nicht immer, daher ist das zu prüfen. Und noch wichtiger: Ein Wiederanlaufkonzept ersetzt kein Recovery. Simples Beispiel: Eine versehentlich gelöschte Datei ist auch im Image bzw. im Replikat gelöscht. Ein Backup, das sich an den nötigen Wiederherstellungserfordernissen ausrichtet, ist also zusätzlich Pflicht. Man sollte nicht immer nur an die "Katastrophe" denken, reale Nutzungsausfälle finden meist auf anderen Ebenen statt. Gruß, Nils
  4. Server spiegeln samt Betriebssystem

    Moin, so ein "Spiegelserver" ist i.d.R. nicht der richtige Ansatz. In der Praxis stellt sich das doch wesentlich aufwändiger und fehlerträchtiger dar, als man zunächst annimmt. Im Grundsatz könnte man sowas zwar etwa über eine VM-Replikation erreichen (der "Hauptserver" ist eine VM auf Virtualisierungs-Hostserver 1, die auf den Virtualisierungs-Hostserver 2 laufend repliziert wird), aber gerade bei solchen "Sammel-Servern" mit AD, ERP usw. ist das Risiko hoch, dass dann im Fall des Falles doch nicht alles funktioniert. Von Versuchen, dort mit regelmäßigen Images zu arbeiten, rate ich komplett ab. Wenn überhaupt, dann sollte man sowas - wie oben skizziert - auf Basis virtueller Maschinen machen und damit die Hardware-Abhängigkeit reduzieren. Wie groß ist denn die Umgebung, von wie vielen Anwendern sprechen wir? Gruß, Nils
  5. Moin, das ist ja genau das, was ich meine: Erzeugen des Ordners genau einmal in dem Moment, in dem der User neu angelegt wird (Skript 1). Verbinden des existierenden Ordners beim Logon des Benutzers (Skript 2). Das kann man durchaus per PowerShell machen, aber wenn man sich damit nicht auskennt, ist Batch einfacher. Skript 1: Angabe des Usernamens und ggf. weiterer Details Erzeugen des Users im AD (PS: New-ADUser, Batch: net user oder dsadd user) Erzeugen des Home-Ordners in einer bestehenden Freigabe, ggf. mit Berechtigungen Skript 2: Verbinden des Homes mit der Angabe der übergeordneten Freigabe und der Systemvariable %username%, ist per PowerShell und Batch ähnlich einfach; Beispiele wirst du im Web viele finden Gruß, Nils PS. es wäre nett, wenn du auf Lesbarkeit deiner Beiträge achtest und grundlegende Zeichensetzung und Groß- und Kleinschreibung einsetzt.
  6. Moin, und das bedeutet, dass das Homeverzeichnis erzeugt werden soll? Das wäre sehr untypisch, denn schließlich muss das nur genau einmal erzeugt werden. Üblicherweise wird in einem Logonscript ein bestehendes Homeverzeichnis verbunden - das ist eine ganz andere Aufgabe und viel einfacher. Solltest du vielleicht noch mal klären. Nein, sorry, aber fertige Scripte schreiben wir hier normalerweise nicht. Das wäre auch wenig zielführend, wenn wir dir deine Aufgaben erledigen, dann hast du nichts gelernt und jemand anders deine Aufgabe erledigt. Gruß, Nils
  7. Moin, also hast du eine exakte Aufgabe gestellt bekommen? Wie lautet die denn? Sonst raten wir hier nur rum und es passt am Ende nicht. Beim Anlegen eines Users über das GUI kannst du direkt ein Home erzeugen lassen. Beim Anlegen per PowerShell gibst du halt in dem Skript, mit dem du den User erzeugst, auch das Kommando, den Ordner zu erzeugen, den Namen dafür hast du in dem Fall ja. Und wenn es darum geht, für bestehende User ein Home zu erzeugen, dann liest man die User aus und lässt in einer Schleife die Ordner anlegen. Dein Skript schlägt deshalb fehl, weil es in der ersten Zeile erwartet, einen Parameter übergeben zu bekommen. Daher stellt die PowerShell beim manuellen Ausführen auch die Nachfrage. Du müsstest diese Stelle ersetzen durch eine Funktion, die den Anmeldenamen des Users zurückgibt, der das Skript aufruft. Dafür käme z.B, die Systemvariable %USERNAME% in Frage. Noch dazu hast du das Skript offenbar von einer Webseite kopiert, weshalb falsche Anführungsstriche darin stehen. Tippe alle Anführungsstriche in einem Texteditor neu. Gruß, Nils
  8. Moin, was genau möchtest du denn erreichen? Dass jeder User ein Homeverzeichnis hat? Das ließe sich wahrscheinlich einfacher erreichen. Allgemein würde man sowas eher zentral erzeugen (z.B. in dem Moment, wenn der User im AD angelegt wird; oder auch einmalig für alle bestehenden Userkonten) als es beim Anmelden eines Users zu tun - nicht zuletzt könnte man damit Berechtigungsprobleme vermeiden. Also beschreibe doch bitte noch mal genau die Aufgabe und das Ziel. Gruß, Nils
  9. Dateiänderung - welcher PC?

    Moin, der Hinweis auf das Auditing ist korrekt. Vorsicht, das muss man an zwei Stellen aktivieren: in der lokalen Richtlinie (gpedit.msc oder per AD-GPO) des Rechners, wo die ini-Datei liegt, die Überwachung als solche aktivieren im Dateisystem das jeweilige Objekt (also vermutlich die ini-Datei) zur Überwachung konfigurieren, das geht über den Berechtigungsdialog. In dem Fall sollte Erfolgsüberwachung für "Jeder" ausreichen. Die Informationen finden sich dann im Security-Eventlog des Rechners, auf dem die Überwachung stattfindet. Hinterher daran denken, die Überwachung wieder abzuschalten. Und noch mal Vorsicht: Solche Auditing-Daten auszuwerten, kann sehr aufwändig sein, weil ein einfacher Dateizugriff leicht mal -zig Detailevents erzeugt. Gruß, Nils
  10. Moin, hilft dies? https://www.faq-o-matic.net/2010/05/21/sql-server-2008-admins-haben-keine-sysadmin-rechte/ Gruß, Nils
  11. Moin, ein paar stichwortartige Empfehlungen: die Domäne nicht "neu machen", sondern beibehalten. Auch in kleinen Umgebungen ist das fast immer die bessere Wahl. Dazu einen neuen DC als zusätzlichen DC in die vorhandene Domäne einbinden und "normal" replizieren lassen. Korrekt, alle Clients (also auch alle anderen Server) müssen die IP-Adresse des neuen DCs als DNS-Server eingetragen bekommen. Die Fileserver-Daten kannst du dann einfach 1:1 auf den neuen Server kopieren, z.B. mit robocopy, das nimmt auch die Berechtigungen mit. Einen Neuaufbau der Beechtigungen würde ich immer nach einer Migration machen, alles andere ist so gut wie immer unpraktikabel. Also: Nach der Übertragung auf den neuen Server läuft alles wie bisher, und dann macht man sich in Ruhe Gedanken, was man wie neu strukturieren möchte und wie man das umsetzt. In einer Umgebung mit mehr als ca. 10 Benutzern sollte man immer mehr als einen DC haben. Trotzdem muss der 2003-DC weg, also einen "dritten" DC installieren und dann den 2003 geordnet entfernen. AD-Backups niemals mit irgendwelchen Kopien, VM-Konzepten oder sonstwas machen, sondern nur auf unterstütztem Weg. Als o über ein Systemstate-Backup (Bordmittel) oder einen AD-Agenten. AD niemals mit Hyper-V auf einem physischen Server kombinieren. Gruß, Nils
  12. Moin, Vorsicht: meines Wissens gelten beim Downgrade immer die Lizenzbedingungen der tatsächlich eingesetzten Version. Ob das unter 2012 erlaubt war, wäre in dem Fall egal, wichtig wäre, ob man 2008 schon zweimal mit einer Hostlizenz einsetzen durfte. Ob das so war, habe ich nicht mehr im Kopf. Gruß, Nils
  13. Hyper V Replizieren! Movelrights?

    Moin, weil man in einem Systemhaus viele Tätigkeiten und Projekte haben kann, die mit "Servern" gar nichts zu tun haben. Ist bei uns (um 100 MA) nicht anders. Und der TO hat ja auch nicht die Aufgabe, das technisch umzusetzen, sondern er soll einen Lizenzfrage klären. Also alles ganz nachvollziehbar. Gruß, Nils
  14. Hyper V Replizieren! Movelrights?

    Moin, es gibt kein "Replizierrecht" und auch keine "Move Rights". Relevant ist der Grundsatz, dass auf dem Host die Lizenzen für die VMs vorliegen müssen. Vereinfacht gesagt: der jetzige "alte" Host muss, wenn dort 5 Windows-Server-VMs laufen, drei WS-Standard-Lizenzen haben (weil jede Std-Lizenz 2 VMs erlaubt) der neue Host muss ebenfalls drei Standard-Lizenzen haben Da der "alte" Host anscheinend weiter laufen soll, muss diese Lizenzzuweisung auch beibehalten werden Also eigentlich ziemlich einfach. Vielleicht sollte euer Vertrieb sich mal in diesen Basics fit machen und die richtigen Ansprechpartner beim Distributor identifizieren. Gruß, Nils
×