Jump to content

NilsK

Expert Member
  • Content Count

    13,534
  • Joined

  • Last visited

Everything posted by NilsK

  1. Moin, ich glaube, du willst lieber das bestehende Problem lösen statt eine Reihe neuer Probleme zu erzeugen. Ihr wollt euren SQL Server nicht nach außen veröffentlichen. Gruß, Nils
  2. Moin, deine Syntax ist von Grund auf falsch. Du kannst die Cmdlets nicht einfach so hintereinander schreiben. Auch kannst du nicht einfach aus einem Parameter einen Vergleich machen. Und schließlich funktioniert die Mehrfachverschachtelung und der Verweis auf Werte nicht so, wie du dir das denkst. Vielleicht solltest du erst mal einfachere Codebeispiele ausprobieren und damit in der PowerShell laufen lernen. Deine jetzige Anforderung ist schon sehr komplex, da sollte man die Basics draufhaben. Gruß, Nils
  3. Moin, ja, die betreffende Partei hat meine Haltung gut erkannt. Gruß, Nils
  4. Moin, hm, ich glaub, ich soll in diesem Leben immer nur dasselbe wählen. 92 Prozent Übereinstimmung ... Gruß, Nils
  5. Moin, weitergehend wäre die Frage, ob solche Accounts überhaupt im produktiven AD richtig aufgehoben sind. Aus Sicherheitssicht wäre zu prüfen, ob man für diese Tests nicht ein separates AD einrichtet. Schließlich habt ihr offenbar eine ganze Reihe von Sessions, die unbeaufsichtigt laufen - und das dann künftig vielleicht auch noch mit Shared Accounts. Gruß, Nils
  6. Moin, ich glaube, du solltest dir noch ein paar Grundlagen aneignen. Sonst wirst du auf Basis fehlender Kenntnisse herumstochern und möglicherweise schwere Fehler erzeugen. Ein AD läuft auf einem bestimmten Modus und hat ein bestimmtes AD-Schema. Beide werden von den vorhandenen DCs vorgegeben. Das Schema muss immer dann aktualisiert werden, wenn ein DC mit einem neueren Betriebssystem eingebunden werden soll, und zwar vorher. Das geschieht (in älteren Versionen) über das ForestPrep. Da noch weitere Anpassungen nötig sein können, gibt es auch noch das ADPrep. Erst dann kann man den "neueren" DC überhaupt als DC dazuinstallieren. Hast du also ein AD mit DCs unter 2003 R2 und willst einen DC mit 2008 dazuhaben - ist ForestPrep und ADPrep erforderlich. Seit Windows Server 2012 (meine ich) ist dieser Schritt direkt in die Installation integriert - er findet immer noch statt, aber nicht mehr separat. Der Modus hingegen gibt an, welche neueren Funktionen im AD aktiv sind. Der mögliche Modus wird vom "ältesten" DC vorgegeben. Solange du also noch 2003-DCs hast, kannst du nicht vom 2003-Modus weg. Wenn du den letzten 2003-DC entfernt hast, hebt sich der Modus aber nicht von selbst an, das muss man manuell tun. Normalerweise ist das auch problemlos, aber es kann "theoretisch" Applikationen geben, die vorher geprüft werden müssen. Exchange ist da der einzige "typische" Fall, weil ältere Exchange-Versionen meist mit den neueren AD-Modi nicht klarkommen. Beide Aspekte (Schema und Modus) haben technisch aber nichts miteinander zu tun. Die Probleme in deinem Lab werden nicht ursächlich damit zu tun haben, da stimmt etwas anderes nicht. Gruß, Nils
  7. Moin, das klingt nicht gut. Dann ist sicher das Eventlog voller Details dazu. Ich wage mal zu vermuten, dass wir das in einem Forum nicht gelöst bekommen. Wenn es sich um eine Produktionsumgebung handelt, solltest du umgehend einen Case bei Microsoft eröffnen. Gruß, Nils
  8. Moin, nur ergänzend dazu aufgrund deiner Anmerkung: Drucker gehören auch nicht auf einen DC, die sind auf einem dedizierten Druckserver genau richtig aufgehoben. Gruß, Nils
  9. Moin, Idee 1: Abwarten, möglicherweise eine Replikationslatenz. Da sollte es aber eigentlich nur um Minuten gehen, wenn überhaupt. Idee 2: Da läuft was falsch. Mehr kann man anhand der Informationen dazu nicht sagen. Gruß, Nils
  10. Moin, naja, es gibt ja keine blöden Fragen. ;) Die Alterungs-Eigenschaften gehören zur Zone, die musst du also nur einmal einstellen. Das solltest du dann auf den anderen Replikaten auch sehen. Das Häkchen auf Server-Ebene setzt du eben nur bei dem Server, der das auch tun soll. Und für den gibst du an, in welchen Abständen er nachsehen und aktiv werden soll. Bei allen anderen Servern setzt/lässt du dieses Häkchen leer. Gruß, Nils
  11. Moin, ja, korrekt, so ist das gemeint. Nur auf die Weise kommst du zu vorhersagbaren Intervallen. Wenn mehrere DCs/DNS-Server den Vorgang ausführen, betrachtet jeder seine Intervalle separat - dadurch überschneiden die sich und man weiß nie, wann nun mit einem Aufräumvorgang zu rechnen ist. Gerade für das Troubleshooting wäre das hinderlich. Gruß, Nils
  12. Moin, das Schema hat nichts mit dem Domain oder Forest Level zu tun. Das Schema ist immer das der neuesten Windows-Version, die als DC im Einsatz ist. Beim Modus ist es eher umgekehrt: Der Modus wird vorgegeben durch die älteste Windows-Version, die als DC im Einsatz ist. Ein neueres Schema ändert funktional nichts. Ein höherer Modus schon. Gruß, Nils
  13. Moin, das ist immer eine Frage der Anforderungen und der Möglichkeiten. Ein Konzept mit dedizierten Admin-Workstations zur Absicherung von Admin-Anmeldungen kann Sinn ergeben, man muss aber immer definieren, welches Szenario man absichern will. Und die Prozesse müssen dazu passen. Bei Microsoft gibt es mittlerweile eine ganze Menge dazu, teils mit sehr detaillierten Vorschlägen, was man einschränken kann. Man mache sich aber nichts vor: Das ist sehr großer Aufwand. Wenn der dazu führt, dass die Admins sich dran vorbeimogeln, hat man wenig gewonnen. Gruß, Nils
  14. Moin, uh, wer baut denn sowas? Ich denke, damit hast du deinen DNS-Server gezwungen, die Einträge zu entfernen, bevor der jeweilige Server eine Chance hatte, sie zu aktualisieren. Schau dir an, was die Werte tatsächlich bedeuten. Die im Lieferzustand gesetzten 7 Tage sind da durchaus realistisch, zumindest als Ausgangspunkt. Zudem sollte nur ein einziger DC in der Domäne den Aufräumvorgang tatsächlich ausführen, sonst kannst du die Intervalle praktisch wieder vergessen. [Endlich Ordnung auf dem DNS-Server | faq-o-matic.net] https://www.faq-o-matic.net/2006/04/30/endlich-ordnung-auf-dem-dns-server/ Parallel wäre es durchaus denkbar, dass es Probleme bei der Registrierung gibt. Dazu solltest du die Eventlogs der beteiligten Systeme prüfen. Und natürlich muss die DNS-Konfiguration aller beteiligten Systeme stimmen, siehe dazu: [Was muss ich beim DNS für Active Directory beachten? (Reloaded) | faq-o-matic.net] https://www.faq-o-matic.net/2007/01/09/was-muss-ich-beim-dns-fuer-active-directory-beachten-reloaded/ Gruß, Nils
  15. Moin, deine Fragen lösen sich nicht mit einem bestimmten Betriebssystem, sondern mit Planung, Erfahrung und Übung. Deine Nachfrage an Tesso ist bereits beantwortet: Du musst am DC nichts einrichten. Der DC verteilt nur die Einstellungen, die du an einer Admin-Workstation zusammenstellst. Eine solche Workstation ist ein PC, auf dem du die Admintools installierst, die du brauchst. In diesem Fall also die RSAT für die AD- und Serverfunktionen. Die Konfigurationen und Einstellungen nimmst du dann mit den Tools auf diesem PC vor, nicht per RDP am Server direkt. Wenn du das so tust, hast du mit hoher Wahrscheinlichkeit auf deiner Admin-Workstation alle Komponenten zur Verfügung, die du für die "eigentlichen" Client-PCs konfigurieren willst. Im Detail können Gruppenrichtlinien durchaus verwirrend sein - hier hilft der erste Satz dieses Beitrags. Gruß, Nils
  16. Pst, du darfst ihren Namen nicht sagen - oder willst du ihr unsere Position verraten?

  17. Moin, bevor es jetzt hier in gegenseitige Beleidigungen abdriftet - verkneift euch doch lieber eine Antwort, wenn es keine sachlich-fachliche ist. Danke. Gruß, Nils
  18. Moin, ich wollte das damit auch nicht abschließend beantworten. Mir war erst mal nur wichtig, dass du benennst, was denn für dich die relevanten Punkte sind. Es findet sich sicher noch jemand mit konkreter Erfahrung. Gruß, Nils
  19. Moin, ich bin kein Mac-Spezi, würde aber behaupten, dass man das ohne Zusatzprodukte hinbekommen sollte. Es ist natürlich anders als bei Windows-Rechnern - das Sicherheitssystem von MacOS beruht auf BSD und ist daher völlig anders als das von Windows. Ebenso braucht ein Mac natürlich andere Druckertreiber, die ein Windows-Druckserver ihm wohl nicht bereitstellen kann. Wird wohl auf Scripting hinauslaufen. Gruß, Nils
  20. Moin, also hast du die Dateisystemberechtigungen schon manipuliert? Da besteht dann ein sehr hohes Fehlerpotenzial. Falls es möglich ist, die VM neu zu erzeugen, würde ich das versuchen. Gruß, Nils
  21. Moin, dann solltet ihr noch mal in euch gehen ... wenn der Aufwand für ein Client-Backup nicht gerechtfertigt ist, sähe ich das Fehlerpotenzial der anderen Ansätze als unvertretbar hoch an. Das beschreibt es - leider - ziemlich gut. Gruß, Nils
  22. Moin, wenn das Konzept so aussähe, riete ich entschieden davon ab. Das wäre eine hervorragende Möglichkeit, sich Probleme zu schaffen, die man nicht braucht. Gruß, Nils
  23. Moin, im Grundsatz verständlich. Bei all diesen Techniken muss man aber "Kosten" und Nutzen gut abwägen - es lauert eine Menge Ungemach unter der Oberfläche. Schau dir mal Folgendes als Startpunkt an: [You searched for folder redirection - Helge Klein] https://helgeklein.com/?s=folder+redirection&submit=Search Vor allem dies hier: [Folder Redirection - Denial of Service Waiting to Happen - Helge Klein] https://helgeklein.com/blog/2011/11/folder-redirection-denial-of-service-waiting-to-happen/ Und wenn wir schon dabei sind, auch noch das: [You searched for offline folders - Helge Klein] https://helgeklein.com/?s=offline+folders&submit=Search In deinem Fall könnte man darüber nachdenken, ob nicht eine Client-Backup-Lösung sinnvoller wäre. Gruß, Nils
  24. Moin, gut, dass du Roaming Profiles loswerden willst. Ordnerumleitungen sind zwar "besser", führen aber auch zu oft zu Problemen. Daher an der Stelle meine Standardfrage: Bist du sicher, dass ihr das überhaupt braucht? Was ist das Einsatzszenario und welche Funktion soll die Ordnerumleitung erfüllen? Gruß, Nils
  25. Moin, und willkommen an Board! Normalerweise treten solche Zugriffsfehler auf Host-Ebene auf, d.h. es scheitert dann bei allen VMs. Dass es hier nur um eine VM geht, ist seltsam. Meine erste Vermutung wäre daher, dass auf dem Quellsystem für die betreffende VM die Berechtigungen anders sind als bei den anderen VMs. Vergleiche mal die NTFS-Berechtigungen der fehlschlagenden VM mit denen einer "erfolgreichen". Gibt es da Unterschiede? Gibt es nähere Hinweise in den Eventlogs? Hier kämen mehrere der Hyper-V-Logs in Frage, also nicht nur unter "System" nachsehen. Gruß, Nils
×
×
  • Create New...