phatair
-
Gesamte Inhalte
505 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von phatair
-
-
vor 5 Minuten schrieb Nobbyaushb:
Ich bin eine großer Fan von einem DC der außerhalb der Virtualisierung läuft, (Lieblingsbeispiel Intel NUC oder ähnlichem..) - hat schon diversen Kunden den Popo gerettet...
Die Idee hatte ich auch schon - einfach noch einen physikalischen DC hinzufügen.
Reicht da so ein kleines Ding wie ein Intel NUC aus? Muss ja eigentlich nicht viel machen und könnte tatsächlich im Falle eines Ausfalles einiges an Arbeit ersparen.
Gerade eben schrieb RolfW:Da eignet sich auch der AD Papierkorb sehr gut :)
Aber nicht bei einem kompletten Ausfall der DCs. :)
-
Danke für den Link, Nils.
Mir geht es im Moment um das Szenario "Disaster Recovery" - z.B. komplettes Storage ausgefallen (wir haben im Moment nur eines, zweites wird gerade realisiert).
Das bisherige Konzept sieht vor, die wichtigsten VMs über Veeam Instant Recovery auf einer eigens dafür vorgesehenen LUN auf einem NAS zu starten und dann später auf das wieder funktionierende Storage zu migrieren. Das würde eben auch bedeuten, dass ich einen unserer DCs im Non-Authoritative Mode wiederherstellen muss. Hier würde ich das Systemstate Backup ja eigentlich nicht brauchen, da ich ja ein komplettes Backup über Veeam habe. Das Systemstate Backup wäre dann eher für den Fall, ich habe mehrere AD Objekte gelöscht und muss im laufenden Betrieb ein Restore durchführen.
Habe auch noch diese Info gefunden - finde Sie sehr interessant. Vielleicht hilft Sie auch anderen, auch wenn es vieles aus deinem Link beinhaltet.
-
vor 19 Minuten schrieb NilsK:
warum Admins bei sowas immer mit "paranoid" kommen, wird sich mir nicht mehr erschließen ...
Naja, war vielleicht ein etwas schlechter Witz - war halt auf den Zeitpunkt bezogen - da die tägliche Sicherung 3 Stunden später sowieso gelaufen wäre und die meisten Leute dann "komisch" schauen.
vor 19 Minuten schrieb NilsK:Ergänzend empfehle ich, ein regelmäßiges AD-Backup mit Bordmitteln herzustellen, also den Systemstate täglich mit Windows Server Backup zu sichern. Beim AD sollte man immer einen doppelten Boden haben (zwei Sicherungsmethoden parallel). Das Systemstate-Backup mit WSB ist die einzige Sicherung, die von Microsoft komplett unterstützt wird. Diese Option sollte man nutzen, zumal sie kaum Aufwand erzeugt.
Danke - das ist ein guter Tipp, daran habe ich noch gar nicht gedacht.
Der Systemstate reicht für die AD Sicherung so aus, oder?
Sicherst du das dann auf ein Netzlaufwerk (mit dem Nachteil das es immer wieder überschrieben wird) oder lässt du es auf die lokale Platte sichern, da diese dann ja mit Veeam auch täglich gesichert wird? Hier könnte ich das Backup ja jederzeit "rausholen".
Würde mir dann zum wiederherstellen der AD das Systemstate Backup ausreichen (mit F8 beim booten des DCs), oder benötige ich dann ein passendes Boot Iso um das Backup einzuspielen?
-
Ja
vor 9 Minuten schrieb NilsK:Moin,
aber ihr sichert euer AD doch hoffentlich täglich?
Gruß, Nils
Jap, die DCs werden täglich mit Veeam und Application-aware processing gesichert.
Ich habe gestern nur ein manuelles Backup angeschmissen, da ich ja Murphys Law kenne und ich sichergehen wollte, dass wir auch ein Backup mit dem neuen DSRM Kennwort haben :)
Man könnte es jetzt auch Paranoid nennen, ja
-
Danke!
Hat wunderbar funktioniert und wir haben gleich ein Backup vom DC erstellt.
Uns reicht der normale DSRM Account - da wir nur 2 DCs haben und das somit sehr übersichtlich ist.
-
Hallo zusammen,
das bisherige DSRM PAsswort der 2012Rs DCs ist bei uns nicht dokumentiert. Ich würde dieses nun gerne ändern.
Kann man das einfach so machen oder muss etwas beachtet werden?
Ich würde mich an diese Anleitung halten
-
Das werde ich jetzt auch so machen - es sind 2 Anwendungen die auch relativ überschaubar sind und keine besonderen Ansprüche an den SQL haben.
Das ist wie mit den Festplatten - hier will jeder Hersteller immer gleich 100GB und am Ende werden nur 40GB genutzt.
@NilsK Ich müsste aber eine neue Instanz erstellen und dann die bestehende DB umziehen, da ich ungern die "named Instanz" für alle zukünftigen DBs verwenden möchte. Das verwirrt dann doch, wenn die Instanz suggeriert, dass sie für eine bestimmte Applikation ist.
Wenn ich dich richtig verstehe, meinst du, dass es technisch möglich ist die bestehende Instanz weiter zu verwenden und einfach alle DBs darin zu nutzen. Nur der Instanz Name bleibt halt "falsch".
Das umbenennen einer Instanz scheint ja nicht zu funktionieren. -
vor 21 Minuten schrieb NilsK:
naja, was für ein Feature würdest du nicht installiert haben? Aber ja, im Prinzip hieße es das.
Die neue Applikation benötigt z.B. das Feature "Integration Services". Das hatten wir bei der bestehenden Instanz nicht installiert, da die bestehende Applikation das nicht benötigt hat.
Bisher habe ich mich beim Anlegen der Instanz und deren Features immer daran orientiert, was die Applikation benötigt.
vor 21 Minuten schrieb NilsK:Du kannst die bestehende Instanz auch so lassen, ein Umzug ist technisch nicht nötig.
Du meinst damit, auf dem SQL Server einfach 2 Instanzen weiterhin laufen lassen. Dann haben wir dort eben eine "named Instanz" und eine "neutrale Instanz" in der in Zukunft alle DBs laufen?
vor 13 Minuten schrieb testperson:ggfs. solltest du das noch, sofern vorhanden, mit dem Hersteller der Applikation(en) klären, ob die das so unterstützen. Es gibt immer wieder Hersteller, die (mindestens) auf eine eigene Instanz pochen und ansonsten (angeblich) den Support verweigern.
Das war der Grund, warum ich das bisher (auf einem SQL Express) so gemacht hatte. Dort hatte ein Hersteller genau diese Anforderung.
Ich dachte nun, wenn es technisch keine Nachteile bietet, dass man das standardmäßig so macht.
Aber das Thema shared Memory ist natürlich schon ein Grund, dass nicht einfach so zu machen.
EDIT: Gerde mit dem Hersteller der neuen Applikation gesprochen - die wollen natürlich eine dedizierte DB Instanz... Wahrscheinlich sagt das jetzt jeder, den wir fragen
-
Hi Nils,
Ok, dass heißt dann auch - habe ich ein Feature bisher noch nicht für die Instanz installiert. Füge ich es eben später der Instanz hinzu.
Dann wäre in unserem Fall wohl die beste Vorgehensweise - neue Instanz mit neutralen Namen erstellen, bestehende DB umziehen, alte Instanz löschen.
Oder übersehe ich hier etwas?
-
Hallo zusammen,
wir haben einen SQL 2017 Standard Server der im Moment mit einer SQL Instanz läuft.
In dieser ist eine DB vorhanden, die für eine Applikation genutzt wird. Die Instanz heißt auch wie die Applikation.
Nun benötigen wir eine weitere DB für eine andere Applikation. Kann ich dafür einfach eine weitere Instanz hinzufügen oder ist es besser eine Instanz zu besitzen in der alle DBs liegen?
Das würde dann natürlich dafür sprechen, die Instanzen nicht nach den Applikationen zu benennen.
Wenn ich unterschiedliche Funktionen benötige, muss ich ja eine weitere Instanz anlegen, oder?
Vielen Dank schon mal.
Gruß
-
Kein Problem :)
Der Exchange 2010 wird bei uns ja auch nicht mehr so lange laufen.
Ich lasse es erstmal über das Out of Office laufen.
Danke Dir trotzdem für deine Hilfe!!
-
Hm...also ich finde leider keine Möglichkeit. Scheint wohl mit Exchange 2010 einfach nicht zu funktionieren.
Bleibt mir wohl erstmal nur das Out of Office.
Die einzige Lösung wäre ein ThirdParty Produkt, aber wir benötigen das im Moment nur für eine Mailbox. Ich hoffe, dass es mit dem neuen Exchange dann besser funktioniert.
Falls noch jemand eine Idee hat oder Du, Norbert, noch eine Lösung findest, freue ich mich natürlich :)
-
Danke Norbert - hat keine Eile.
Das heißt, Exchange 2010 kann diese serverseitige Regel einfach noch nicht, richtig?
Hier hat jemand das gleiche Problem. Als Lösung wird gesagt:
ZitatOn the server
You need to have the Allow automatic replies option enabled in Exchange for this to work.
Open "Exchange Management Console", expand "Organization Configuration" -> "Hub Transport". In the right pane, select the "Remote Domains" tab.
Right click "Default" and choose "Properties".
On the "General" tab, you can set which type of Out of Office Messages you will allow to be sent out. By default, only external OOF messages are allowed. You can change the option to also allow OOF messages created by Outlook 2003 and previous.
On the tab named "Format of original message sent as attachment to journal report" (Exchange 2007) or "Message Format" (Exchange 2010), you can enable or disable the automatic
replying/forwarding.
Bei uns ist "Nur externe Abwesenheitsnachrichten zulassen" aktiviert. Damit hat das aber doch nichts zu tun, oder?
-
Das dachte ich auch schon. Hier habe ich aber die Option "diese vom Server mit einer Nachricht beantworten" nicht...
Wird wohl langsam dringend Zeit auf Exchange 2019 zu wechseln?!?
Wir nutzen ja noch Exchange 2010 SP3
-
Hi Norbert,
ok - ich würde auch gerne weiterhin Variante 2 nutzen aber ich bin einfach zu blöde hier die Möglichkeit zu finden eine Regel für den Account zu erstellen, mit der ich eben Absender eine bestimmte Mail zurückschicken kann (Auto-Reply).
Wenn ich das Konto hinzufüge, kann ich in den Regeln oben auswählen, auf welches Postfach die Regel wirkt. Dann kann ich im Assistenten die Option angeben "diese vom Server mit einer Nachricht beantworten".
Wenn ich das Konto nicht hinzufüge, sondern nur das Postfach zusätzlich einbinden (Variante 2), dann habe ich bei den Regeln gar nicht die Möglichkeit eine Regel für dieses Postfach zu erstellen.
Wo mache ich das dann?
Ich könnte natürlich auch den Abwesenheitsagenten nutzen, aber dieser schickt ja nur 1x pro Absender eine Mail. Ich fände eine Regel für unseren Fall sinnvoller.
-
Danke euch.
hat wunderbar funktioniert.
Eine Frage habe ich noch.
Für die Shared Mailbox soll ein Auto-Reply eingerichtet werden. Das würde ich gerne über eine Regel durchführen. Hier hätte ich ja die Möglichkeit eine Nachricht zu verschicken (Have server reply using a specific message).
Ich habe ja jetzt die Shared Mailbox dem User unter "zusätzliche Postfächer" hinzugefügt.
Um die Regel für das Postfach anzulegen, müsste ich dem User unter "Datei" - "Konto hinzufügen" das Gruppenpostfach hinzufügen und könnte dann die Regel dafür erstellen.
Kann ich mir dann das Postfach unter "zusätzliche Postfächer" sparen oder sind das 2 unterschiedliche Einstellungen und werden beide benötigt?
Das zusätzliche Postfach erscheint dann ja auch in Outlook - für mich sieht das nach dem gleichen Ergebnis aus, nur das ich dann auch die Regeln für das Postfach erstellen kann.
-
-
Hat jetzt alles wunderbar funktioniert, nach dem ich mich mit dem Schema Master verbunden hatte - danke Martin.
Habe jetzt alles umgesetzt und Berechtigungen werden für neue GPOs korrekt gesetzt. Die AD Gruppe darf auch GPOs bearbeiten und verlinken.
Vielen Dank an euch und vor allem Mark für die super Anleitung!
-
vor 11 Minuten schrieb daabm:
Wer ist Schema-Master?
(netdom query fsmo) Ist dein adsiedit mit dem verbunden? Und was sagt "repadmin /showreps"?
Schema-Master ist unserer 2. DC (mit dem war ich nicht verbunden). Muss ich mit dem Schema Master verbunden sein?
repadmin /showreps zeigt aktuelle Daten und alles erfolgreich an. Ausgeführt auf dem 1. DC (von dem ich ADSI-Edit ausgeführt hatte).
-
Hm..nicht das ich wüsste. DCDiag zeigt auch keinerlei Fehler an.
Ich habe beim verbinden mit dem ADSI-Editor direkt einen DC ausgewählt (Pfad:LDAP://DC1.kts.schlaeger.com/Schema
Ist das vielleicht ein Problem - muss ich beim Verbinden unter "Computer" nicht "Standard (Domäne oder Server, an der/dem Sie angemeldet sind)" auswählen, sondern "Domäne oder Server auswählen oder eingeben:" und dort dann den Domänennamen angeben?
-
Panische Angst nicht, aber schon etwas Respekt davor
Es gibt aber leider ein Problem beim ändern des Werts defaultSecurityDescriptor. Ich habe auf einem DC den ADSI-Editor geöffnet, mich mit dem Schema verbunden und bin zum CN-Group-Policy-Container navigiert.
Ich erhalte folgende Fehlermeldung beim Übernehmen der Änderung.
Unser Default Wert lautet:
D:P(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)
Marks Wert ist identisch (nur die Sortierung ist anders).
Diesem Wert habe ich dann (A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;<SID DER GPO GRUPPE>) angehängt.
Also so:
D:P(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;DA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;EA)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;CO)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;SY)(A;CI;LCRPLORC;;;AU)(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)(A;CI;LCRPLORC;;;ED)(A;CI;CCDCLCSWRPWPDTLOSDRCWDWO;;;<SID DER GPO GRUPPE>)
Hab ich irgendwas übersehen?
-
Danke Dir.
Erhöhen solche Änderungen im Schema nicht auch die Fehleranfälligkeit z.B. bei einem DC Update und dem damit verbundenen Schema Update?
-
Hallo zusammen,
ich muss leider noch einen Beitrag aufmachen - die Umstrukturierung der Admin Accounts zieht ganz schöne Kreise :)
Ich möchte eine GPO Admin Delegierung durchführen. Dazu hab ich 2 Beiträge gefunden
Vom Mark
Von 4Sysops
Die beiden Beiträge unterscheiden sich aber etwas:
Marks Variante ändert das AD Schema ab, damit bei allen GPOs die neue Sicherheitsgruppe mit den Berechtigungen korrekt übernommen werden.
Die Variante von 4Sysops fügt erstmal in AD Benutzer und Computer die Sicherheitsgruppe hinzu, danach wird per powershell befehl für jede GPO die Berechtigung angepasst. Das ganze wird dann per Scheduled Task immer wieder durchgeführt, um neue GPOs auch mit der Berechtigung zu versehen.
Ich habe immer noch das (vielleicht veraltete Info) das Schema Änderungen vermieden werden sollten. Wäre somit die 4Sysops Variante die bessere oder ist die Mark Variante problemlos durchführbar?
Danke euch schon mal.
Gruß
-
Habe ich auch nicht als Empfehlung aufgenommen.
Danke Dir!
Managed Service Accounts - ein paar Fragen
in Active Directory Forum
Geschrieben
Hallo zusammen,
wir haben bei uns bisher "Service Accounts" so definiert, dass es normale AD User waren die einen bestimmten Namensschema gefolgt sind. Diese hatten die Option "Passwort läuft nicht ab" und "User kann Passwort nicht ändern" aktiviert.
Diese Accounts wurden nur für eine festgelegte Aufgabe verwendet.
Nun gibt es ja auch die Möglichkeit Managend Service Accounts (ab 2008R2) und Group Managend Service Account (ab 2012) zu verwenden. Das wären dann "richtige" Service Accounts.
Ich hätte dazu ein paar Fragen und vielleicht kann mir diese jemand beantworten:
Vielen Dank.
Gruß