MurdocX

Ich hatte mit Zertifikaten damals auch kein einfaches Thema. Mit Passion an der Technik wird das schon. Das sind Techniken die du eh später brauchen kannst. Viel Erfolg und vor allem und viel Spaß! Dir wird ja schon kompetent geholfen :)

Es steht Dir immer noch frei das vorher in Frage zu stellen. Immerhin, wenn Fehler auftauchen, wirst erstmal du gelöchert und musst dich erklären.

Ich bin da geteilter Meinung. Einerseits, wenn das alles sauber konfiguriert ist, mag das schon funktionieren. Andererseits sehe ich jetzt nicht den Vorteil der zweiten NIC. Meiner Erfahrung nach fehlen vielen Softwareunternehmen die Basics. Wenn man nach dem warum fragt, wird’s schnell dünn.

Die direkten Steps hab ich auch nicht. Hier wäre eine Konfigurationsanleitung, für die eigene Umsetzung. Das was du suchst nennt sich "Split Tunneling" ASA/AnyConnect: Dynamic Split Tunneling Configuration Example https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/215383-asa-anyconnect-dynamic-split-tunneling.html

Das klingt ein bisschen wirr, bzw. nur aus deiner direkter Sicht. Da fehlt es am drumherum. Über NAT beschreibst du den Weg-> rein und über DNS-Auflösung eigentlich den Weg raus. Du könntest auch den RDCM und RDSH über den externen DNS-Namen von intern mit der internen IP ansprechen. Ohne das du mehr Infos schreibst, schließe ich mich @testperson an.

Oh nein, Microsoft klaut Admins die Arbeit

Bin der gleichen Meinung. Ich hab mich eine Zeit lang mit dem Thema intensiv beschäftigt und poste jetzt meine geschriebene gekürzte produktiv Interna. Mit Absicht hab ich die unteren ACL-Set´s drin gelassen, damit du (und andere) die als Vorlage verwendet werden kannst/können. Der Fehler kommt, wenn: Der DC das Objekt nicht findet Die Replikation zum anderen DC noch aussteht und er deshalb dort das Objekt nicht findet Er es nicht abrufen darf Alles Weitere hilft Dir nicht direkt, zeigt aber Möglichkeiten für die Berechtigung und dem Umgang mit NT-Account und auflösen der SID für Tests. (Das Skript wurde aus dem Kontext gerissen und oben angepasst, sollte aber soweit passen) Das Skript macht folgendes: Generiert einen NT-Account Ruft die SID ab ( versucht das mehrmals, denn die Replikation ist meist noch nicht durch ) Baut die ACL Fügt diese zum RuleSet hinzu Set die ACL Wichtig: Es ist zu unterscheiden, ob eine Berechtigung auf eine Datei oder einen Ordner gesetzt wird. $beispielDomain = "zielDomain.local" $beispielName = "meineDomain\IchBinUser" $objAdNtAccount_RWGroup = New-Object -TypeName System.Security.Principal.NTAccount -ArgumentList ( $beispielDomain, $beispielName ) # INIT-Do $Ende = $false $Trys = 1 do { # Versuche den Abruf so lange, bis es klappt try { # Get Group SID Write-Verbose -Message "Versuch $Trys von 10, um die SID vom DC abzurufen..." $strAdRwGroupSID = $objAdNtAccount_RWGroup.Translate([Security.Principal.SecurityIdentifier]) # Schleifen abbruch $Ende = $true } catch { # Error is happened, try again! $Ende = $false $Trys++ Start-Sleep -Seconds 6 if ($Trys -gt 10) { # Abbruchbedingung OK, kein Auflösen möglich Write-Verbose -Message "[New-PoProjekt] Fehler: $_" Write-Warning -Message '[New-PoProjekt] Abbruch, da die SID vom DC nicht abgerufen werden konnte!' Break } } } while ($Ende -eq $false) # # Create ACL-Rule # # Null setzen $objDirectoryAceRuleRW = $null $objDirectoryAceRuleR = $null # ACL - Ordner - Berechtigung 'ReadAndExecute' auf oberster Ebene [System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleRW = [System.Security.AccessControl.FileSystemAccessRule]::new(` $strAdRwGroupSID,` [System.Security.AccessControl.FileSystemRights]::ReadAndExecute -bor [System.Security.AccessControl.FileSystemRights]::Write,` [System.Security.AccessControl.InheritanceFlags]::None,` [System.Security.AccessControl.PropagationFlags]::NoPropagateInherit,` [System.Security.AccessControl.AccessControlType]::Allow ` ) # ACL - Ordner - Berechtigung 'Modify' NUR auf Unterordner und Dateien [System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleRW2 = [System.Security.AccessControl.FileSystemAccessRule]::new(` $strAdRwGroupSID,` [System.Security.AccessControl.FileSystemRights]::Modify,` [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit,` [System.Security.AccessControl.PropagationFlags]::InheritOnly,` [System.Security.AccessControl.AccessControlType]::Allow ` ) # ACL - Ordner - Berechtigung 'ReadAndExecute' NUR auf Unterordner und Dateien [System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleR = [System.Security.AccessControl.FileSystemAccessRule]::new(` $strAdRGroupSID,` [System.Security.AccessControl.FileSystemRights]::ReadAndExecute,` [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit,` [System.Security.AccessControl.PropagationFlags]::None,` [System.Security.AccessControl.AccessControlType]::Allow ` ) # ACL - Dateien - Berechtigung 'Modify' aber ohne 'Delete' [System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleMgr = [System.Security.AccessControl.FileSystemAccessRule]::new(` $strAdMgrGroupSID,` [System.Security.AccessControl.FileSystemRights]::ReadAndExecute -bor [System.Security.AccessControl.FileSystemRights]::WriteData -bor ` [System.Security.AccessControl.FileSystemRights]::AppendData -bor [System.Security.AccessControl.FileSystemRights]::WriteAttributes -bor ` [System.Security.AccessControl.FileSystemRights]::WriteExtendedAttributes, ` [System.Security.AccessControl.InheritanceFlags]::None ,` [System.Security.AccessControl.PropagationFlags]::None,` [System.Security.AccessControl.AccessControlType]::Allow ` ) # ACL - Dateien - Berechtigung 'ReadAndExecute' [System.Security.AccessControl.FileSystemAccessRule]$objDirectoryAceRuleMgr2 = [System.Security.AccessControl.FileSystemAccessRule]::new(` $strAdMgrGroupSID,` [System.Security.AccessControl.FileSystemRights]::ReadAndExecute,` [System.Security.AccessControl.InheritanceFlags]::None,` [System.Security.AccessControl.PropagationFlags]::None,` [System.Security.AccessControl.AccessControlType]::Allow ` ) ## Setzen der Berechtigung auf den ProjektOrdner # GET ACL Rule from File $objDirectoryAceNow = Get-Acl -Path $ProjektPfad -ErrorAction Stop # ADD New ACL Rule $objDirectoryAceNow.AddAccessRule($objDirectoryAceRuleRW) # SET New ACL Rule to File $objDirectoryAceNow | Set-Acl -Path $ProjektPfad -ErrorAction Stop

Für alle die es nicht mitbekommen haben, möchte ich hiermit informieren. Jetzt live und kostenlos. psconf.eu Virtual Mini Conference http://powershell.one/psconfeu/psconf.eu-2020/about

Das ist auch eine Kostenfrage. Für RDS sind Lizenzen notwendig. Wir haben RemoteApps im Einsatz und sind sehr zufrieden damit.

Es steht Dir auch frei, wie du das machen möchtest. Ein Eindruck von Anderen, kann zur Unterstützung der eigenen Einschätzung beitragen.

Auch ich kann für unsere Windows Server Palette nur bestätigen, dass wir schon länger keine Probleme mehr mit Updates hatten. Ich hab den WSUS bei uns automatisiert. Damit läuft das Thema nur noch nebenbei.

Die Fehlermeldung "Critical process died" hatte ich schon in Kombination mit defektem RAM. Das könnte für Dich ein Ansatzpunkt sein.

Das kannst du durchaus mit der Powershell machen. Mehrere Probleme hast du dann bei der Umsetzung anzugehen. Da man ja eine gewisse Zuverlässigkeit des Skripts braucht und durchaus auch Erfahrung, würde ich Dir das Thema nicht empfehlen. Dafür dürfte es fertige Lösungen geben.

Ich wollt’s nur erwähnen. Es gibt viele die unnötig alles herunterladen, weil sie’s einfach nicht besser wissen. Bezüglich „Beta Tests“ habe ich bisher kaum bis keine schlechten Erfahrungen gemacht. Man hört immer viel, dennoch sind es meist irgendwelche Spezialfälle oder nur wenige betroffen. Ich genehmige (bzw. hab’s geskriptet) mit Ausnahmen alles benötigte. Probleme hab ich und Kollegen nie.

Damit lädst du eindeutig zu viel runter. Das solltest du nicht nutzen, sondern deine Updates die deine Clients anfordern genehmigen. Um das zu automatisieren gibt’s auch Skripte.

Habe ich Dich richtig verstanden, das du von uns wissen möchtest wie man den Server knackt?

Schau Dir mal das hier an: Map FTP to a Drive Letter Without Driver Installations https://gallery.technet.microsoft.com/Map-FTP-to-a-Drive-Letter-42c3efb1

Wenn die User das Skript verändern können, welches als SYSTEM ausgeführt wird, dann ist das die eleganteste Methode Admin-Credentials abzugreifen und das Netzwerk zu übernehmen...

Es könnte auch das hier sein: Kurioser Audio-Bug nach Windows 10-Patch: Kein Ton oder doppelt | Winfuture https://winfuture.de/news,115997.html

Das würde ich auch empfehlen. Da das Tool auch Firmware-Updates ausliefert. Installationen sind soweit zuverlässig. Des Weiteren würde ich nicht anfangen bei den Treibern an einzelnen Dateien zu werkeln. Die hängen als Paket immer zusammen und sind getestet. Da kann man sich schnell "komische Effekte" ins Haus holen. Das will man ja auch wiederum nicht. Bei mir wurde übrigens schon solche Fehler durch Firmware-Updates fabriziert & gelöst. Es ist nie verkehrt darauf zu setzen.

Da bin ich deiner Meinung. Ein wenig mehr Übersicht zu bekommen würde nicht schaden. Ich könnte mir auch vorstellen, dass das Debugging/Troubleshooting dann wieder etwas einfacher von der Hand fällt. Ich war mehr als überrascht, dass das nicht in Powershell umgesetzt wurde. Das wäre irgendwie das naheliegendste gewesen.

Und wieder in INI-Dateien wühlen? Neee, lass ma. Klar hat man das Ding schon inhaltlich wenig verändern können. War aber auch nicht dramatisch. Ich finde auch das die Registry (auch technisch) gut gelungen ist.

Siehe Edit. Schau Dir bitte mal IseSteroids an. Das gibts auch in einer Testversion, die sollte für Dein Script reichen. Dann siehst du die Probleme schneller. Diese Objekte werden erst innerhalb der DoLoop-Schleife definiert und es ist zum Schleifenende nicht klar, ob diese überhaupt existieren. Abschlussbedingen werden vorher definiert und nur gefüllt. Das Objekt sollte dann schon Instanziert (erstellt) worden sein. Die letzten Klammern und das "break" haben da nichts verloren, denn die Schleife wird mit Until beendet und irgendwie wieder geöffnet als neue Schleife. https://www.windowspro.de/script/schleifen-powershell-foreach-while-do-until-continue-break } Until(($TestingDriveUSB.Driveletter -eq $DUMMYletter) -and ($TestingdriveID.deviceid -eq $DUMMYusbID) -or ($loopUSBcheck -gt 25)){ break }

Der Teil unter "#------Anzeige aller Laufwerk vom Typ "Entfernbar"---------#" sollte auskommentiert sein? Puh. Der Code ist - mit Verlaub - wirklich unsauber geschrieben. Da muss dringend mehr Ordentlichkeit rein. Gerade bei der Größe... Manchmal Echo, dann wieder write-output dann mit @ Klammer () Befehle sind nicht ausgeschrieben (where ?) > where-object Abschnitte laufen über Region https://devblogs.microsoft.com/scripting/use-regions-in-powershell-ise-2/ Variablen deklarierst du oben einmal, nicht bei jedem DoLoop Kommentare kommen an den Zeilenanfang, nicht zwischendrin Ein Befehl pro Zeile bspw. Warum verwendest du eigentlich Start-Sleep? Fragen über Fragen... Übrigens willkommen an Board

Wäre auch der elegantere Weg. Spart auf jeden Fall Arbeit und Probleme. Den neuen Speicherort würde ich dann noch der Indizierung hinzufügen.