daabm

Hm - "keep it simple" ... Wenn das Server sind, warum liefern die dann nicht die Daten, statt man sie von einer zentralen Stelle aus holt? Würde ich zumindest so machen - entweder auf nem Share oder in ne Datenbank, und wer nicht liefert, muß halt untersucht werden. Und bei knapp 600 Servern würde ich mal über PRTG oder ähnliches nachdenken - man kann ja schon ab und zu mal ein Rad neu erfinden, sollte aber über die Gesamtkosten nachdenken.

Ordnerumleitung hat Einstellungen für das Verhalten beim Entfernen - wenn das "unpassend" konfiguriert ist, bleibt die Umleitung auch bei nicht mehr angewendeter GPO weiter bestehen. Und aus der Erfahrung:

Keep it simple - tu Dir das mit verschiedenen Pfaden pro Benutzergruppe nicht an. Am "einfachsten und zuverlässigsten" funktioniert die Umleitung, wenn Deine User ein Homeset im AD-Account haben, mit %homeshare%%homepath% (ja, die GUI meckert - aber zu Unrecht - wenn Du das einträgst... Und nein, da fehlt kein Backslash). Dann muß für FR noch "Anwenden ohne Änderung" aktiviert werden, falls das Homeset mal umzieht - https://gpsearch.azurewebsites.net/#324

Das ist aber unnötig, wenn man alle seine Shares nicht "direkt" bereitstellt, sondern - sinnvollerweise - ausschließlich über DFS-Namespaces. Dann ändert sich dort nur das Verweisziel.

Du merkst schon, da kommt man schnell vom 100sten ins 1000ste

BTW: Man kann die Ordnerumleitung auch "komplett selbstkontrolliert" gestalten: https://evilgpo.blogspot.com/2014/10/implementieren-von-ordner-nur-auf.html

(Geht auch unter Windows 10 noch...) Wahnsinn - auch schon wieder 6 Jahre alt, der Post

Dann sag dem DHCP doch auf allen Scopes, daß er die Adressen im DNS registrieren soll...

Wer ist denn auf den Clients so als DNS eingetragen? (ipconfig /all)

Und was sagt ein "nltest /dsgetdc:" (kein Tippfehler, der sinnlos wirkende Doppelpunkt am Ende gehört dazu...)

vor 11 Stunden schrieb MurdocX:

Zu NT4 Zeiten hatte ich noch andere Prioritäten 

Bewußtseinserweiterung und Erhaltung der Art? Oder noch "schneller mit dem Kettcar um die Ecke"? 

Bin jetzt kein DHCP-Profi, aber da könnte was machbar sein mit der Class ID. Ist normalerweise leer, kann per ipconfig oder Registry gesetzt werden. Und der DHCP-Server kann das iwie auswerten und was damit anstellen.

Weil die alten nicht dran denken, daß jemand das über den neuen Kram versuchen könnte?

Am 9.10.2020 um 17:24 schrieb Mr_Marple:

Ist ja schon eine Weile her, aber ich würde das einfach über ein Login Skript machen.

 

echo %date% %time% %username% %computername% >> \\dc1.domain.local\sysvol\domain.local\login\txt.txt

DC1 deshalb, damit es nur eine Version gibt und sich nichts drüber repliziert.

Abgesehen vom Problem der Verhaltens- und Leistungskontrolle, das vorher unbedingt (!) geklärt werden muß: So funktioniert das garantiert nicht, weil alle "gleichzeitig" in das gleiche File schreiben. Und warum das auf Sysvol liegen sollte, weißt auch nur Du.

Entweder gleich richtig (also in eine Datenbank) oder wenigstens in ein individuelles File pro User und/oder pro Client (in der Annahme, daß sich ein User immer nur zu einer Zeit wo anmeldet und daß sich auf einem Client immer nur ein User gleichzeitig anmeldet).

Ohne AD wird das sehr schwer zentral zu steuern. Gäbe noch InTune, kostet aber auch nicht "nichts". Als "Domain Controller" für AD könntet Ihr auch Samba 4 nehmen, dann muß wenigstens nur die HW bezahlt werden. Auch wenn Du da dann bei der Software zumindest in diesem Board eher wenig Support finden wirst.

16x4 gibt bei mir 64 Clients, und ein paar in Reserve sollten auch noch vorhanden sein. In den meisten Firmen stehen bei der PC-Menge 2 VM-Hosts mit ca. 6 bis 12 virtuellen Servern, und das dürfte Gründe haben.

Was Norbert meint: Schlangenöl... Lufthaken... Feilenfett... Ölwannenbeleuchtung... Kolbenrückholfeder... ? Defender reicht völlig, Brain 2.0 ist 1000x wichtiger. Gegen APTs hilft kein AV.

Am 9.10.2020 um 12:25 schrieb BOfH_666:

Ich weiß nicht, was der "inspirierende Modus" ist

Mein "inspirierender Modus" hängt hinter der Couch an der Wand Nennt sich Regal und enthält Whisky (oder auch Whiskey) in etwa 25 Varianten. Ansonsten konnte ich mit dem Begriff bisher auch nichts anfangen - und ich hoffe sehr, daß mir das auch in Zukunft erspart bleibt. Das ist so "End-User Fitzelkram", der ist der Alptraum jedes Admins. [/OT]

Stand oben schon mal: Wenn das XML ist, gibt es keinen Grund für "Zeile 12 ändern". Wenn Du diese Dateien als XML lädst, kannst Du relativ komfortabel darin navigieren und Eigenschaften (= Properties) sowie Inhalte (= Nodes) ändern. Dazu müßtest Du aber mal zeigen, was Du schon hast und wie so ein XML aussieht.

Ansonsten bin ich bei Olaf: Wer's falsch angeliefert hat, könnte es doch auch richtig anliefern? Und "mehrere tausend" hat ja sicher ein Automatismus erstellt, der könnte das ja ein zweites Mal "korrekt tun"

PS: VBS spreche ich zwar noch, habe damit aber schon seit ca. 5 Jahren kaum noch etwas gemacht. Powershell wäre wirklich die bessere Alternative.

Ojeh - DHCP/DNS/Firewall/VPN-Änderungen remote klingt nach "Ast, auf dem ich sitze"... Hier sogar gleich 4 Äste. Ich würde das dringend vor Ort machen wollen.

Ich würde ja einfach nen neuen Bereich anlegen und dann den alten deaktivieren bzw. entsorgen. Ich weiß ja nicht, was an Reservierungen etc. vorhanden ist (ok, paar Excludes sieht man), aber wenn Du das Bereichsnetz änderst, paßt das ja alles nicht mehr zum neuen Bereich.

Hey, keine Ursache - schön, wenn ich so ein Feedback kriege, danke dafür Und übrigens auch Kompliment, daß Du das mit meinen doch nicht sooo dummy-tauglichen Infos umgesetzt hast. Das ist heutzutage leider selten geworden...

Ändere den Startmodus von Manuell auf Automatisch, dann dürften die meisten weg sein. Oder lebe halt damit

@falkebo wenn ich das richtig weiß, kannst auf jeder Standard-Blechlizenz 2 VMs betreiben. Ein Filer braucht kaum Ressourcen außer ein wenig Netz und Platte (und auch das wird meist überschätzt), ein Spooler noch weniger. Wenn man das heute also auf Blech auf einer Maschine hat, spricht für mich alles dafür, das morgen als VM auf dem gleichen Blech getrennt laufen zu lassen.

vor 8 Stunden schrieb BOfH_666:

Bei manchen MSI-Installationen zeigen die Startmenu-Icons nicht auf die .EXE sondern auf die unterhalb vom Windows-Verzeichnis abgelegte .MSI Datei. Das sind dann sogenannte "advertised shortcut".

Bevor da jetzt einer in die Eigenschaften schaut - nein, die zeigen nicht auf die MSI-Datei. Die zeigen auf das "Installer-Objekt" (ich weiß nicht, wie ich's einfacher beschreiben soll), das triggert dann einen Teil des MSI-Pakets (das dann z.B. trotz computerbezogener Installation noch userbezogene Nachinstallation machen kann) und startet dann die im Installer-Objekt hinterlegte Zieldatei. Aber jetzt ist [/OT]

Ich wüßte spontan nichts  - aber im Security Compliance Toolkit war irgendwas drin mit Policy Compare, da würde ich mal suchen...

Alternativ kann Quest GPOAdmin das auf jeden Fall sehr gut (das weiß ich sicher), das ist aber nicht ganz umsonst.

vor 5 Stunden schrieb Dominik Weber:

Der Kunde möchte nur 3 Accounts, da die Buchhaltungssoftware im Einsatz eine Named User Lizenzierung hat.

Es sind fix 2 Mitarbeiter in der Buchhaltung und eben die Abteilungsleiter und der Chef die ab und zu rein möchten und sich teilweise gegenseitig rausschmeissen.

Ich erinnere mich dunkel, daß hier im Board keine Unterstützung kommt, wenn es um Lizenz-"Konstrukte" geht...

vor 7 Stunden schrieb KlausKleber:

also mittlerweile habe ich rausgefunden, dass das erstellen von Symbolischen Links immer Adminrechte erfordert.

Nein, tut es nicht. Das ist ein Windows-Recht, das man per GPO jedem geben kann, wenn es Not tut. Und ich persönlich finde diesen Weg nicht sooo falsch - bei Picasa ging das ja seinerzeit auch nur mit Symlinks, wenn man eine gemeinsame DB auf mehreren Rechnern nutzen wollte. Die Ordnerumleitung von "Bilder" ist natürlich der insgesamt schlüssigere Weg

https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/create-symbolic-links

Die ISE hat den von Olaf erwähnten Vorteil: Ist Powershell da, ist auch eine ISE da. Der Rest ist immer nur optional...

Moin im Board. Hast Du eine alte Fritzbox übrig? Die ist Switch, Access Point und Router in einem und kann damit alles erfüllen, was Du für B haben willst. Und wenn in A auch schon eine FB steht, geht's mit dem AVM Mesh sogar für Einsteiger relativ einfach, nur das Cat6-Kabel muß noch einer durch das Rohr ziehen

Merke - nicht jedes Postfix ist ein Mailer

Fast Ich hab ein Startskript, das den Namen und den DN der OU in eine Umgebungsvariable schreibt. Kurzname in Deinem Beispiel "WEBSERVICE", DN dann OU=Webservice,OU=irgendwas,DC=contoso.

Die Gruppen in der GPO sind generische definiert als %ServiceOU%-Admins, %ServiceOU%-Users etc. Die Zielgruppenadressierung geht auf nen sAMAccountName %ServiceOU%-Admins mit ner Searchbase von LDAP://%ServiceOUDN%. GPP löst diese Variablen zur Laufzeit auf (was ja in den "alten" Benutzerrechten nicht geht).

Die GPO hängt über allen Services. Leg ne neue OU an, steck nen Server rein. Nach dem ersten Reboot sind die Umgebungsvariablen da, nach dem 2. Reboot stimmen die Benutzerrechte.

Der Rest (diese 47 Rechtegruppen) funktioniert nach dem gleichen Schema.

Jeder Service hat natürlich auch ne Standardgruppe für Serviceaccounts - Du ahnst es schon, %ServiceOU%-ServiceAccounts. Die stecken in der seServiceLogonRight Gruppe (und in seBatchLogonRight). Das kann man beliebig granular weiter runterbrechen, aber Admins, Users, Serviceaccounts reichte uns.

Ich glaub, ich muß da mal ne Blogpost dazu machen

Die Gruppen dürfen nur Domain Admins bearbeiten - und der Service Account des IDM, über das man die zugehörigen Rollen beantragt. Da es aber immer nach "Schema F" läuft, ist sogar das relativ easy.

PS: Die Gruppennamen bei uns sind anders - wir haben noch ein paar Prä- und Postfixe. Aber für das Prinzip spielt das keine Rolle.

vor 10 Stunden schrieb PrometricDriver:

Gut zu wissen weil mir bei Recherchen hier im Forum eben genau dieser Link schon öfters untergekommen ist und ich das in etwas abgewandelter Form jetzt in einem Lab implementiert hab

und das eigentlich soweit richtig gut funktioniert.

Der Link läuft vermutlich ziemlich vielen über den Weg - nur verstehen leider auch ziemlich viele nicht, was darin für Möglichkeiten liegen, diese lästige Delegation von Admin-Rechten zu vereinfachen. Aber wie schon mehrfach geschrieben wurde: Gut, daß wieder einer anfängt, den alten Kram aufzuräumen

BTW: Wir haben im aktuellen Neu-Design nur noch eine Policy, die Admin- und User-Rechte auf allen (!) Member-Servern regelt. Alle Server eines "Service" liegen in einer OU. Für diese OU wird eine Umgebungsvariable gebildet (Startskript). Und diese Variable ist auch Bestandteil der Namen der delegierten Admin- und Usergruppen. Neuer Service? Kein Problem - OU anlegen, Maschine reindeployen. Gruppen anlegen, fertig. GPO ist schon da... Und natürlich hat diese GPO für alle delegierten Gruppen eine Zielgruppenadressierung - die Gruppe MUSS sich in der OU befinden, in der auch der Server ist (LDAP-Filter - braucht keine 5 ms). Sonst könnte ja wer irgendwo anders eine entsprechende Gruppe anlegen.