NilsK

Moin, nicht automatisch. Das hängt immer sehr von den Gegebenheiten ab. Den gewählten Weg halte ich für grundsätzlich völlig OK. Gruß, Nils

Moin, doch, doch, das ist schon korrekt. Der erste DC einer Domäne konvertiert seine lokalen Benutzer in Domänenbenutzer. In dem Fall stimmt die Aussage also. Alle weiteren DCs hingegen schalten ihre SAM ab und löschen alle Objekte daraus. Auch beim Herunterstufen eines DC findet keine Konvertierung "AD-User zu lokalem User" statt, weil sich in dem Fall schlicht die Felder nicht sinnvoll abbilden lassen. Gruß, Nils

Moin, wenn die PowerShell nichts zurückgibt, bedeutet das meist, dass der Vorgang erfolgreich war. Man könnte Jans Ansatz noch etwas eleganter machen und in mehrere Teile zerlegen. Dann sieht man auch besser, wo evtl. noch ein Fehler ist. Gruß, Nils

Moin, genau das hat er ja vor. Er möchte die Gruppen, die seinem Standard-User (quasi als Vorlage) zugewiesen sind, auch dem neuen User zuweisen. Ein durchaus übliches Vorhaben. Solange kein Identity Management im Spiel ist, kann man das auch so machen. Jans Kommandozeile sollte das auch erreichen. Gruß, Nils

Moin, die Syntax haben wir dir schon fast vorgegeben, nur noch nicht mit den SQL-Statements. Da du anscheinend anfängst, SQL zu lernen, solltest du versuchen, dir das anhand des geschilderten Algirithmus' zu erarbeiten. Da du mit SQL bislang noch nichts zu tun hattest, solltest du dich zunächst mit sehr einfachen Abfragen an die Sprache herantasten. Was du als Aufgabe beschrieben hast, ist schon ziemlich fortgeschritten. Mach lieber einen Schritt nach dem anderen. Hier findest du z.B. eine allererste Übersicht - aber das Web ist voll von guten Einführungen zu SQL. [Grundbefehle von SQL | faq-o-matic.net] http://www.faq-o-matic.net/2002/03/17/grundbefehle-von-sql-2/ Gruß, Nils

Moin, gerade bei der RAM-Ausstattung muss man dem Händler genau sagen, was man will. Üblicherweise bestellen die einfach nach Liste und haben keine Kompetenz, das Geeignete selbst zu finden. Wenn man da Unterstützung braucht, muss man die ausdrücklich anfordern. Nur so als Tipp für die Zukunft. Gruß, Nils

Moin, ja, guter Hinweis, das könnte sein. Dazu müsste man die Logik der Datenbank bzw. der Applikation kennen, um das zu entscheiden. Die Aussage "zurückgeschrieben" in der Anfrage lässt das offen. Hm, GROUP BY sehe ich da jetzt nicht, weil ja nach einer konkreten Kostenstelle gefragt wird. Da reicht ein normaler Filter vermutlich aus. Gruß, Nils

Moin, nein, an der angegebenen Stelle trägst du nichts ein. Das würde bedeuten, dass der User sich nur an den angegebenen Rechnern lokal (mit Konsolensitzung) anmelden darf. In deinem Szenario müsste der User sich mit einem lokalen Konto an den Client anmelden und dann beim Zugriffsversuch auf die Freigabe das Domänenkonto mit Kennwort angeben. Gruß, Nils

Moin, "wähle den Wert Maximum aus der Spalte Kostenstelle sowie den Wert Maximum aus der Spalte Betrag addiert mit 1 aus, wo in der Spalte Kostenstelle '30300' steht". Und wenn das Ergebnis stimmt, ersetzt du das "Wähle aus"-Statement durch das "Aktualisiere"-Statement. Gruß, Nils

Moin, auch das ist beantwortet. Wenn DHCP auf einem DC läuft, braucht man genau für solche Dinge das Proxy-Konto. Sonst kann der Eintrag nicht überschrieben werden. Die PTR-Einträge zu löschen, hätte einmalig auch funktioniert, aber die nächste Änderung wäre dann schon wieder nicht möglich gewesen. Gruß, Nils

Moin, es geht doch jetzt, hat er gesagt. Die Beschreibung ist auch plausibel. Gruß, Nils

Moin, ... und das Eventlog sagt dazu ...? Gruß, Nils PS. da es ja offenbar nicht brauchbar läuft, würde ich zügig prüfen, ob das Problem nach Ausbau weg ist. Sowas kann an defektem RAM liegen und auch gern in Datenverlusten enden.

Moin, ja, bei dem Konto geht es genau um das beobachtete Phänomen. Wird immer wieder falsch verstanden (weil es ausgesprochen schlecht dokumentiert ist). Schön, dass du den richtigen Weg gefunden hast. Daraus entnehme ich, dass DHCP auf einem Domänencontroller läuft. Kann man machen, wäre aber bei Gelegenheit mal zu überdenken. Gruß, Nils

Moin, ergänzend zu Dukels Fragen: Verschwindet das Problem, wenn ihr das RAM wieder zurückbaut? Gruß, Nils

Moin, ja, nach nochmaligem Drübersehen habe ich gemerkt, dass ich die Angaben beim UCS zum AD wohl falsch interpretiert habe. Die Einbindung in die UCS-eigenen Domänendienste (vermutlich Samba 4.x) gibt es auch schon in der kostenlosen Fassung. Für ein Heimszenario dann evtl. ausreichend. Ginge es um ein Kleinunternehmen, würden die <500 Euro für Essentials nicht ins Gewicht fallen. Gruß, Nils

Moin, sind die "Apps" denn überhaupt so dynamisch, dass man DFS-R braucht? Normalerweise tut es robocopy in solchen Situationen auch. Sind die Dateitypen evtl. von der Replikation ausgeschlossen? DFS-R ist ja eigentlich für ganz andere Zwecke gedacht. Gruß, Nils

Moin, in dem gegebenen Szenario wohl eher uninteressant. Der UCS ist nicht relevant günstiger als ein Windows Essentials 2012 R2 und kann kein "echtes" Active Directory. Das wäre immer viel Gebastel und gerade nicht einfach. Essentials wäre von den Funktionen und vom Preis her durchaus eine gute Wahl. Man darf ihn auch als VM betreiben. Und er braucht keine CALs. Technisch käme auch Foundation in Frage, aber das gibt es nur vorinstalliert als OEM-Version. Gruß, Nils

Moin, das ist nicht AD, sondern AD LDS. Ganz anderes Produkt und für den angegebenen Zweck gar nicht geeignet. Gruß, Nils

Moin, unbenommen. Es spricht allerdings auch einiges dafür, Patches eben nicht flächendeckend "sofort" einzuspielen, sondern durchaus mehrere Wochen zu warten. Die letzten Jahre haben gezeigt, dass die Qualität der Updates leider nicht immer ausreicht, um sich auf ein reibungsloses Verfahren zu verlassen. Das Risiko, durch schnelles Patchen erst recht Probleme zu erzeugen, ist leider real. Daher empfehle ich ebenfalls dringend, grundsätzlich "schnell" zu patchen, besonders bei zentralen und/oder sicherheitskritischen Systemen. Eine Wartezeit von mehreren Wochen kann ich aber eben aufgrund der Stabilitätsrisiken nicht als "unverantwortlich" bezeichnen. Gruß, Nils PS. abgesehen davon, ist es eine unbelegte Vermutung, dass der TO mehr als zwei Monate nicht gepatcht habe, nur weil er sich erst gestern hier gemeldet hat.

Moin, das kann ich in dieser Absolutheit nicht unterschreiben. Gruß, Nils

Moin, ... weil in einer kleineren Umgebung schlicht die Ressourcen dazu fehlen. Und selbst wenn: Um die Fehler, die aus dem hier diskutierten Update entstehen, überhaupt zu bemerken, ist eine sehr umfangreiche Testumgebung nötig, in der dann sehr umfangreich getestet wird. In der Qualität treffe ich das i.d.R. nicht mal in Enterprise-Unternehmen an. Gruß, Nils

Moin, ich denke, den Zeitverzug kann er sich sparen. Da Hyper-V auf einem SBS nicht supported ist, gehe ich davon aus, dass Microsofts Support da auch nicht hilft. Gruß, Nils

Moin, wie sollen wir dir aus der Ferne sagen, warum die Updates hängenbleiben? Natürlich könntest du versuchen, in den abgesicherten Modus zu starten und herauszufinden, was das Problem ist. Dafür wirst du aber lokal arbeiten müssen. Und vielleicht kriegst du das Problem nicht behoben. Ich denke schon, dass du rechtzeitig mit einem Restore anfangen solltest. Gruß, Nils PS. und dass man auf einem Produktionssystem nicht herumspielt oder Sachen "mal ausprobiert", hast du jetzt hoffentlich gelernt.

Moin, ich würde das noch mal deutlicher sagen: Hyper-V installiert man NIE, NIE, NIE parallel zu anderen Rollen! Hyper-V ist keine Anwendungssoftware wie VirtualBox oder VMware Player. Es ist ein Hypervisor, der den gesamten Systemaufbau verändert. [Warum der Hyper-V-Host keine (!) weiteren Dienste ausführen sollte | faq-o-matic.net] http://www.faq-o-matic.net/2010/05/03/warum-der-hyper-v-host-keine-weiteren-dienste-ausfhren-sollte/ Der sinnvollste Weg wäre jetzt, das aktuellste Backup des Systems wiederherzustellen. Gruß, Nils

Moin, dann schau dir doch mal die Mitglieder der Gruppe an ... kleiner Tipp: Es ist ein Domänenrechner. net localgroup Benutzer Gruß, Nils