NilsK

Moin, zunächst mal ist deine Tabelle offenkundig nicht normalisiert. Das macht den Umgang damit unnötig kompliziert. Dann: Wenn du nach Datum filtern möchtest, muss es natürlich in jeder Zeile auch ein Datumsfeld geben. Ist das gegeben? Und schließlich musst du mit einer verschachtelten Abfrage arbeiten, auch "Sub-Select" genannt. Mit dem ersten Select identifizierst du alle IDs, für die ein Eintrag "AG" existiert und mit dem zweiten davon dann diejenigen, die kein "RT" haben. Die Klausel "NOT IN" sollte dir dabei helfen (zeige mir nur diejenigen aus Abfrage 1, die in Abfrage 2 nicht auftauchen). Gruß, Nils

Moin, naja, du kannst dir ja auch ein Skript dafür schreiben. Und dabei kannst du dir dann sogar von Excel helfen lassen. [Excel: Admins unbekannter Liebling | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/19/excel-admins-unbekannter-liebling/ Ach so, und wo wir dabei sind: Wenn die Datenbanken auf "Full Recovery Model" stehen, musst du zwingend regelmäßig Log-Backups machen. (Es sei denn, das meinst du mit "Incremental".) http://www.faq-o-matic.net/2011/01/03/sql-server-wie-datenablage-backup-und-recovery-funktionieren/ Gruß, Nils

Moin, nö, das hab ich ja vor drei Jahren schon gemacht. OK, wusste ich nicht, dass die Antworten so anwachsen. Wieder was gelernt. Gruß, Nils

Moin, wie ich oben schon erwähnte: Always on ohne zentrales Storage setzt einiges an Design voraus - und vor allem müssen die Applikationen das können. Das ist nicht automatisch gegeben, gerade bei administrativen Datenbanken. Bevor ich zu so einem Konstrukt greifen würde, würde ich lieber die vorhandene Umgebung reparieren. Ist ja nicht so, dass man mit der genannten Ausstattung keinen zuverlässigen Cluster hinbekäme.Und: Gehe nicht davon aus, dass ein anderes Konstrukt einfach so läuft, das muss man genauso richtig machen. Aber mal ehrlich: Für solche Datenbanken willst du einen Cluster bauen? Gruß, Nils

Moin, bitte nutze Groß- und Kleinschreibung. Du machst es sonst unnötig schwer, deine Beiträge zu lesen. Danke. Prüfungen mit "12 oder 13" Antwortmöglichkeiten (Multiple Choice) habe ich in den letzten 15 Jahren nicht gesehen, auch nicht zu Exchange 2010. Meinst du vielleicht was anderes? Gruß, Nils

Moin, den SOFS würdest du separat installieren, nicht auf denselben Servern. Allgemein ist Hochverfügbarkeit und Sparsamkeit nur selten sinnvoll zu vereinen. Wenn das Budget keinen sinnvollen Cluster hergibt, dann sind offenbar die Anforderungen nicht so hoch. Sind sie es doch, dann muss man auch das Budget dafür einplanen. Einen "klassischen" Failover-Cluster setzt du auch weiterhin mit einem geeigneten (!) zentralen Storage auf. Du kannst auch andere "Always on"-Mechanismen nutzen, die ohne zentrales Storage auskommen - das setzt aber ebenso einiges an Aufwand, Hardware und Design voraus. Vor allem aber muss es von den Applikationen unterstützt werden, die auf die Datenbank zugreifen, und das ist oft das K.O.-Kriterium. Wenn das Budget keinen sinnvollen Cluster-Aufbau erlaubt, dann kommst du aber auch mit anderen Methoden zu einem schnellen Wiederanlauf nach einem Ausfall. Mit einem gut entworfenen und vor allem getesteten und dokumentierten Recovery-Verfahren etwa kann man durchaus in einer Stunde wieder online sein. Gruß, Nils

Moin, vom Aufbau her war die Prüfung wie immer. Bei der zweiten einige Szenarien mit längeren Informationsblöcken und gezielten Fragen dazu. Aber klassisch wie beim Millionär mit meist vier Antwortmöglichkeiten. Inhaltlich sollte man die wichtigsten PowerShell-Kommandos und, wie Norbert schon sagt, vor allem in der zweiten Prüfung die "abseitigen" neuen Funktionen kennen, die man in der Praxis selten einsetzt. Gruß, Nils

Moin, bei einem DC, der selbst auch DNS ist, reicht die Einstellung, die Adresse im DNS nicht zu registrieren, nicht aus. Er wird alle Adressen registrieren, auf die der DNS-Dienst gebunden ist. Das muss man dann also auch noch abstellen - was aber auch bedeutet, dass auf der Adresse eben kein DNS-Server antwortet. Ob das mit RRAS auch geht, weiß ich nicht - sowas macht man auf einem DC einfach nicht, daher teste ich es auch nicht. Gruß, Nils

Moin, willkommen an Board - schön, dass du uns gefunden hast! Um das beurteilen zu können, müsste man zunächst einmal wissen, was genau ihr denn erreichen wollt. "Wir haben Mitarbeiter unterwegs oder zuhause" gibt ja noch nicht die Anforderungen an. Was sollen die genau machen? Wo soll die zentrale IT-Umgebung ins Spiel kommen? Allgemein sind grafikintensive Programme am besten lokal auf einem Rechner zu betreiben. Auch YouTube usw. wird man am besten mit einem lokalen Browser nutzen. Bei einem virtuellen Client liefe ja alles auf einer virtuellen Maschine, in deinem Fall auch noch im Rechenzentrum des Providers. Der Mitarbeiter könnte also nur mit einem Remoteprotokoll zugreifen, und das auch noch über die begrenzte Bandbreite seiner eigenen Internetverbindung. Für anspruchsvolle Grafik reicht das normalerweise nicht aus. "Grafikintensiv" und "Thin Client" funktioniert i.d.R. nur innerhalb eines LAN und setzt sowohl auf dem Server als auch bei den Thin Client einiges an Spezialtechnik voraus, das schnell deutlich teurer ist als eine lokale Ausstattung. Bedenke auch, dass eine Thin-Client-Umgebung voraussetzt, dass man immer online ist - hat die Leitung beim Enduser mal ein Problem, kann er gar nicht arbeiten. Wenn dieser Provider euch eine Server-VM mit 9 GB anbietet, wird das für 15 User mit hohen Anforderungen kaum reichen. Für reine Office-Aufgaben usw. wäre das okay. Wie gesagt, so richtig ist ja nicht klar, was ihr erreichen wollt. Vielleicht wäre aber eine Kombination aus "Mittelklasse-PCs" für den lokalen Betrieb der anspruchsvollen Anwendungen und eine Anbindung für Mail und gemeinsame Datenablage beim Provider interessant. Das ist mittlerweile ein Standardprodukt, das du durchaus für fünf bis 25 Euro pro Platz und Monat bekommst. Gruß, Nils

Moin, der übliche Weg besteht darin, die Datenbank vom Server abzuhängen, dann die vorhandenen Transaktionsprotokolle zu verschieben und danach die Datenbank mit Verweis auf die neuen Speicherorte wieder anzuhängen. Eine Bing-Suche nach "sql server move transaction log" zeigt dir eine Reihe von Artikeln, die das beschreiben. EDIT: Die Technik mit dem Mountpoint würde ich eher nicht anwenden. Sie erhöht die Komplexität und erschwert späteres Troubleshooting. Gruß, Nils

Moin, :) passt scho. Ich wollte auch eher die Mitlesenden auf den Unterschied hinweisen. Gruß, Nils

Moin, mit dem Domänen- und Forest-Betriebsmodus schränkst du in erster Linie ein, welches Betriebssystem die DCs haben können. Kurz gesagt, können keine DC-Betriebssysteme eingesetzt werden, die "unterhalb" des jeweiligen Betriebsmodus liegen. Der Forest-Modus 2008 R2 ist dringend anzustreben, weil erst damit der AD-Papierkorb zur Verfügung steht. Voraussetzung: Alle DCs im gangen Forest müssen mindestens 2008 R2 ausführen, und alle Domänen müssen auf (mindestens) diesen Modus angehoben sein. Wenn die NT-Rechner in der Domäne bleiben sollen, musst du in der Tat die NT-Verschlüsselungsoption aktivieren. Hier wäre aber zu prüfen, ob die NT-Rechner wirklich Domänenmitglieder bleiben müssen oder ob dort nicht evtl. ein Zugriff auf bestimmte Shares ausreicht. Den könnte man dann auch individuell konfigurieren, ohne die NT-Rechner in der Domäne zu lassen und ohne die Domänensicherheit herabzusetzen. Dasselbe würde ich auch für die DOS-Rechner empfehlen: Die sind ja ohnehin nicht Mitglieder der Domäne. Hier reicht es aus, den Zugriff auf die jeweiligen Shares zu ermöglichen. Das erfordert dann ggf. das Abschalten des SMB Signing auf den betreffenden Dateiservern sowie - vermutlich am einfachsten - das Einrichten lokaler Accounts für den Zugriff auf den Share. Gruß, Nils

Moin, lefg, deine Lösung hat den Nachteil, dass sie nur in einem deutschen Windows funktioniert. Der Code von Martin dürfte sogar einigermaßen sprachneutral sein. Gruß, Nils

Moin, ich würde einfach nichts konfigurieren. Dann kannst du auch nicht vergessen, es wieder anzuschalten, wenn der VM-DC läuft. In einer Testumgebung stören die Replikations-Fehlermeldungen im Eventlog ja nicht. Ich bleibe dabei, dass das Design unsinnig ist. Gründe und Stichwörter haben wir ja jetzt zur Genüge genannt. Daher klinke ich mich hier jetzt aus. Gruß, Nils

Moin, was du da beschreibst, wird dir sehr schnell (naja ... nach 60 oder 180 Tagen) ein Problem mit Lingering Objects erzeugen. Du solltest das Design deiner Testumgebung noch mal überdenken. Gruß, Nils

Moin, schau an, dann sollte ich meine Vorbehalte gegenüber WMIC vielleicht mal überdenken. ;) Den FIND-Filter für IPv4 kannst du dir aber eigentlich sparen, wenn du sowieso nach einem IPv4-Adressfragment filterst, oder? Aber ich denke, das ginge dann schon in Richtung Haarspalterei ... jedenfalls eine sehr hübsche Zeile, die da entstanden ist. :D Gruß, Nils

Moin, wmic erfordert lokale Adminrechte. Dürfte für den Zweck ungeeignet sein. Ganz ehrlich, mit einer FOR-Schleife und den Fragmenten, die ich hier schon genannt habe, bekommt man das hin. Der Trick ist: Mit FIND filterst du aus der Ausgabe von ipconfig die Zeile, die du brauchst. Mit FOR isolierst du dann den Teil nach dem Doppelpunkt. Versuch es einfach mal. Gruß, Nils

Moin, das wirst du mit der Ausgabe von ipconfig | find /i "10.220" und einem FOR-Konstrukt mit delims=: hinbekommen. Musst du ein wenig mit basteln. Hab ich grad keine Zeit zu. Gruß, Nils

Moin, insbesondere bei FOR gibt es einen Unterschied zwischen der Verwendung im Batch und auf der Kommandozeile. Direkt im CMD-Fenster musst du ein einzelnes Prozentzeichen angeben, im Batch zwei. Wenn du sichergehen willst, dass du die IPv4-Adresse bekommst, dann erweitere das ping-Kommando um den Schalter -4: for /f "Tokens=2 Delims=[] skip=1" %%i in ('ping -4 -n 1 %computername%') do set IPAdress=%%i Gruß, Nils

Moin, oder in einer Inventarisierung. Auch wenn das AD sehr praktisch ist, ist es eben kein allgemeiner Datenspeicher. Gruß, Nils

Moin, nimm dies: [Anmelde Skript: IP Adresse und Subnetz als Variable setzen] http://www.gruppenrichtlinien.de/artikel/anmelde-skript-ip-adresse-und-subnetz-als-variable-setzen/ Gruß, Nils

Moin, die Kennwortrichtlinie kann man auslesen mit: net accounts /domain Da steht dann allerdings nicht dabei, ob die Komplexität eingefordert wird. Die müsste man allerdings ohnehin separat erläutern, denn die einzelnen Kriterien werden nirgends benannt, weil sie ja ohnehin nur an- oder abschaltbar sind. Man kann diese Daten auch per ADSI und VBS, PowerShell usw. aus dem AD auslesen. Das ist für jeden authentisierten Nutzer lesbar. Gruß, Nils

Moin, naja, so in etwa. Mit Ausnahme sehr weniger Spezialfälle ist so eine Konfiguration eher als Fehlkonfiguration zu bewerten. Gruß, Nils

Moin, nein, das ist so nicht richtig. Dafür müssen die Karten i.d.R. als Team konfiguriert sein. Und noch dazu braucht man Applikationen, die mehrere Netzwerkverbindungen parallel laufen lassen können. Sonst verteilt sich da gar nichts. Gruß, Nils

Moin, neu aufsetzen dürfte am schnellsten gehen. Anscheinend hattest du ja noch nichts Produktives laufen. Selbst wenn du es richtig machst: Bist du dir sicher, dass du Kontingente einrichten willst? Die Technik ist nicht besonders leistungsfähig. Und die organisatorischen Folgen sind nicht ohne. Gruß, Nils