NilsK

Moin, tatsächlich keinerlei Fehlermeldungen? Eventlog? Dann tippe ich auf die Hardware. Speicher, CPU ... Gruß, Nils

Moin, das waren immer nur Empfehlungen und zu keiner Zeit strenge Vorgaben. Es geht immer nur darum, dass das Gruppenkonzept von Windows-Domänen (das im AD eigentlich nur leicht erweitert weiterbesteht) eine hohe Strukturierung und Skalierbarkeit zulässt. Will man das nutzen, dann ist es von Vorteil, das auf eine beszimmte Weise zu tun. Insofern gelten die Empfehlungen natürlich noch immer, aber eben nur als Empfehlungen. Man kann es auch anders machen, wenn man möchte, man braucht nicht mal Gründe dafür. Aufpassen sollte man nur in MOC-Prüfungen, wobei man dort oft feststellt, dass die Fragesteller das Prinzip selbst nicht so richtig verstanden haben. Siehe auch: [Windows-Gruppen richtig nutzen | faq-o-matic.net] http://www.faq-o-matic.net/2011/03/07/windows-gruppen-richtig-nutzen/ Gruß, Nils

Moin, wenn du anzweifelst, dass der von Norbert genannte Link, der meiner Kenntnis nach seit 20 Jahren zutrifft, das Phänomen richtig beschreibt - hast du denn schon mal geprüft, ob die Ordner in deinem Fall wirklich schreibgeschützt sind? Gruß, Nils

Moin, ich sehe weiterhin keinen Grund für GROUP BY und würde es mit einem einfachen Filter machen. Also, hier mein Vorschlag, diesmal dann eben als Code: SELECT MAX(Kostenstelle), MAX(Bestellnr) + 1 FROM Tabelle WHERE Kostenstelle = '30300' Und wenn das passt: INSERT INTO Tabelle (Kostenstelle, Bestellnr) SELECT MAX(Kostenstelle), MAX(Bestellnr) + 1 FROM Tabelle WHERE Kostenstelle = '30300' Aber ganz ehrlich, ich kann mir nicht vorstellen, wie jemand das Lösen einer doch recht komplexen Anfrage dieser Art jemandem übergibt, der SQL nicht kennt. Am Ende musst du damit selbst umgehen - aber ich werde das Gefühl nicht los, dass wir hier für jemanden gerade die Hausaufgaben erledigen, und das mache ich ungern. Gruß, Nils

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