BOfH_666

Warum? Welche Aufgabe willst Du denn wirklich damit lösen? Ich gehe davon aus, dass Du das bereits weißt, aber ich wiederhole es einfach zur Sicherheit nochmal: .bat/.cmd/batch ist ziemlich obsolet und wurde schon vor 'ner ganzen Weile durch die viel mächtigere Powershell ersetzt - besonders wenn es um komplexere Aufgaben geht. Es gibt quasi nix, was Du mit .bat/.cmd/batch machen konntest, was Du nicht genauso oder einfacher und besser mit Powershell machen kannst. Wenn Du vorhast, noch eine Weile in "Windows-Umgebungen unterwegs zu sein", empfehle ich Dir dringend, Dich mit Powershell zu beschäftigen. Das wird Dir das Leben erleichtern und ich bin mir sicher, dass es sich für Dich auszahlen wird.

Du kannst die execution policy nicht aus einem Script heraus ändern, wenn das Ausführen von Scripten noch nciht zugelassen ist ... das ist so ähnlich wie ein Henne - Ei - Problem .... Du musst die Execution policy entsprechend anpassen bevor du das Script startest.

Ich hab auch schon mal von nem Kollegen gehört, der von einem anderen Kollegen gehört hat, dass er einfach mal nach sowas gesucht hat und tatsächlich auch noch fündig geworden ist ... aber ich glaube, das war nur ein Gerücht.

Du wirst aber bestimmt auch verstehen, dass wir hier, ohne den Code der Macros zu kennen und ohne die genauen Umstände zu kennen, nicht wirklich viel Hilfreiches beitragen können. Das ist bestenfalls "Raten auf hohem Niveau" - sorry.

Wie wäre es, den Ersteller der Datei / der Macros einzuspanne? Der sollte wissen, wie man dem Fehler auf den Grund gehen kann.

Ich hab's grad mal bei mir getestet und ich fürchte, Du wirst Dir wohl doch ein klein wenig mehr Mühe machen müssen. $template = Get-ADUser -Identity <sAMAccountName> -Properties City,Department,Description,DisplayName,info,MemberOf,Office,OfficePhone,Organization New-ADUser -Instance $template -Name InstanceTest -SamAccountName InstanceTest -DisplayName InstanceTest -Path '<distinguished Name der Ziel-OU>' -UserPrincipalName InstanceTest@<domain> -Enabled $false Mit diesem Schnipsel konnte ich einen neuen Account anlegen. Es ist also empfehlenswert, einen speziellen Vorlagen-Benutzer anzulegen, bei dem auch nur die nötigsten Attribute gepflegt sind. Und es hilft, auch nur die Attribute zu extrahieren, die man wirklich kopiert haben möchte. Alles andere Eindeutige übergibt man dann beim Anlagen des neuen Benutzers. .... probier ma!

Na sag ich doch ... deswegen ist es egal ob man wie rakli schreibt: New-ADUser Test-rakli -Instance $user oder eben wie Sunny New-AdUser -Name 'Test Rakli' -Instance $user Nur dass die beiden eben nicht den gleichen Namen benutzen. .... und dass (wie ich glaube) der Name wegen des Bindestrichs bei rakli auch in Gänsefüßchen gehört.

Hab ich 'n Knick in der Optik? ... die beiden Code-Schnipsel sind doch nahezu gleich - nur dass Sunny einmal einen benannten Parameter benutzt und rakli den Wert für Name eben implizit übergibt!?!? Das einzige Problem, dass ich sehe, ist das der Name einen Bindestrich enthält und deshalb in Gänsefüßchen gehört.

... wir haben 2018!! Wenn der Kollege immernoch PS-Version 2.0 verwendet, gehört er sowieso geteert und gefedert!

Möchtest Du denn für den neuen Benutzer "Test-rakli" wirklich nur die Eigenschaft "Name" ändern? Alles andere soll gleich dem Benutzer "Lehmann" bleiben? Ist der Benutzer "Lehmann" ein Template-Konto?

Wär das nicht der Fall gewesen, hätte die Fehlemeldung anders ausgesehen. Ausserdem braucht man das seit Powershell Version 3 nicht mehr explizit zu machen. Das macht die Powershell automatisch für Dich.

Es ist weniger das Format als eher der Typ. Es macht keinen Sinn Zahlen mit Strings zu vergleichen. Du musst also die Strings in Zahlen umwandeln. z.B. [INT]$LAENGE oder [SINGLE]$LAENGE oder [FLOAT]$LAENGE .... je nach dem, was für Zahlen Du verarbeiten möchtest. Hier ein paar weitere INfos dazu: https://ss64.com/ps/syntax-datatypes.html

.... das ist ja Deine Entscheidung ... wie oben schon mal erwähnt .... die anderen Quotas kann man mit fsutil verwalten.

Wenn Du die FSRM-Quotas nicht verwendest, kannst Du aber auch die FSRM-cmdlets nicht verwenden, oder? Das sind, wenn ich nicht irre, zwei verschiedene Geschichten. Edit: Für die andere Sorte Quotas ist dann fsutil vorhanden ... ein bissl sperriger vielleicht, aber immerhin auch ein Kommandozeilen-Tool.

Das ist ja auch so. Du stellst Quotas für Verzeichnisse ein - nicht für User. Jedenfalls ist mir nix anderes bekannt.

Dass Du ne Fehlemeldung erhältst, hättest Du aber auch ein bissl früher erwähnen dürfen. Wenn Get-FSRMQuota meint, dass auf dem Ordner noch keine Quota gesetzt ist, wird es damit vermutlich Recht haben. Hast Du's über die FSRM-Konsole mal geprüft?

Is nich mein Tach heute ... ich steh irgendwie immernoch auf'm Schlauch ... Du hast also schon ein Script, mit dem Du Quotas für User-Verzeichnisse verwaltest. Und brauchst jetzt ein Script, mit dem Du Quotas für "Standorte" verwaltest. Und wo klemmt's da jetzt? Kannst Du das Script nicht für die Standorte "adaptieren"?

hmmm .... dann ist vielleicht jetzt der Zeitpunkt erreicht, an dem es nicht mehr genügt. Wenn Du für jeden Benutzer eine Quota gesetzt hast, dann ist ja auch alles in Butter, oder? Ich versteh irgendwie immernoch nicht, wo jetzt das eigentliche Problem liegt. Wenn die Einstellungen per FSRM nciht ausreichen und Du ein Script bauen möchtest/musst, na dann musst Du das halt tun.

... soweit ist mir das schon klar ... wenn der Speicher, um den es geht von einem Windows-Server verwaltet wird und das ein Domain-integrierter Fileserver ist, auf dem auch die Rolle Datei-Server aktiviert ist, solltest Du noch zusätzlich die Rolle "Ressourcen-Manager für Dateiserver" installieren, falls das noch nicht passiert ist. Dort lassen sich deutlich detailiertere Einstellungen vornhmen als nur mit der "normalen" Oberfläche, die Du über den Explorer aufrufst.

Wenn ich das nicht falsch im Kopf habe, musst Du ein Template erstellen und das auf den Ordner anwenden, in dem die Freigaben für die Home-Shares erstellt werden. Das kann man mit dem FSRM prima zusammenklicken ... da braucht man kein Script. Das Template wirkt dann auf alle neu erstellten Ordner unterhalb des Ordners, auf dem Du das Template anwendest. ... oder hab ich da was falsch verstanden? Warum willst DU überhaupt eine Quota auf ein ganzes Laufwerk legen?

Hmmm ... ich fürchte, das wirst Du selber bauen müssen. Für ein anderes Projekt ging es bei mir auch mal darum, einen Domain-User auszuwählen. Ich hab dann den Nachnamen auf der Konsole abgefragt, das AD nach allen Vorkommen dieses Nachnamens abgeklappert und ein Liste zum Auswählen präsentiert, falls der Nachname mehrmals vorkam. ... soll ja gelegentlich vorkommen. Was genau heißt: "... komme ich leider nicht weiter"? Ein bissl genauer müsstest Du das schon ausschmücken.

Hmmm ... was ist die eigentliche Frage? Welchen Befehl suchst Du?

Wenn noch keine Quota auf dem Ordner vorhanden ist, muss erstmal eine erstellt werden ... das ist hoffentlich klar ... oder? Bei mir funktioniert es zum Testen so: $TestPath = "OrdnerPfad zum Testen" [INT]$InitialQuota = Read-Host -Prompt "Initial Quota" [UINT64]$InitialQuota = [INT]$InitialQuota * 1GB New-FsrmQuota -Path $TestPath -Size $InitialQuota [INT]$NewQuota = Read-Host -Prompt "Initial Quota" [UINT64]$NewQuota = [INT]$NewQuota * 1GB Set-FSRMQuota -Path $TestPath -Size $NewQuota Remove-FsrmQuota -Path $TestPath -Confirm:$false

Wie schon im anderen Thread geschrieben - wir helfen gern aber wir erstellen keine gebrauchsfertigen Lösungen auf Anfrage. Sollte nicht sowieso jeder Benutzer seine eigene INI-Datei in seinem Profilverzeichnis haben? Wenn das, aus welchem Grund auch immer, nicht so sein sollte, könntest Du das mit einem Script erledigen, welches z.B. im Autostart jedes Benutzers liegt. Für Powershell gibt es Module, die die INI-Bearbeitung erleichtern. Oder Du benutzt einfach die normalen String-Operationen. Wenn der Rest der INI-Datei gleich bleibt, könntest Du auch einfach für jeden Benutzer eine komplette INI-Datei erstellen und diese dann Benutzerabhängig in den richtigen Ordner kopieren. Das verlangt am wenigsten Kenntnisse.

Wir helfen Dir gern. Aber wir werden nicht Deinen Job für Dich machen.