testperson

Hi, AFAIK kann man im WPP Kataloge(?) der Hersteller - sofern verfügbar - importieren/abonnieren. Ansonsten gibt es ja genügend 3rd Party Patch-Management- / Deployment-Lösungen. Letztlich zahlt man entweder Geld in Form von Zeit oder in Form von Lizenzen. Gruß Jan P.S.: Wenn es bei euch "nur" 20 Clients sind, könntest du einen Blick auf Desktop Central von Manage Engine werfen. Die bieten eine kostenlose Lösung für bis zu 25 Clients.

Dann würde ich den Ablauf einfach aktiviert lassen (und den Chef auf "Bl*dsinn" hinweisen)?! Meiner Erfahrung nach ändert niemand sein Passwort nur weil eine E-Mail ihn dazu bewegen möchte. ;)

powershell.exe -NoLogo -NoProfile -ExecutionPolicy Bypass -Command "& { Get-ChildItem -Path \"\\\\<Pfad>\\<zu den PDFs>\" -Filter *.pdf | ForEach-Object { Start-Process $_.FullName -Verb PrintTo \"\\\\<Printserver>\\<Drucker>\" } }" ;)

Hi, ein wenig OT: Ich würde den Bezug zum Kennwortalter einfach weglassen und die User (un)regelmäßig informieren / schulen / sensibilisieren, dass beim Verdacht der Kennwort Kompromittierung das Passwort ASAP zu ändern (und IT / GL / Manager zu informieren) ist. Gruß Jan

Vielleicht den Lehrer einmal hinzuziehen? Der sollte doch für Rückfragen / Probleme da sein.

Hi, welchen Stand hat denn der Exchange 2013: https://www.nobbysweb.de/blog/index.php?entry/41-build-nummern-tabellarisch/ Wenn es tatsächlich der o.g. Build ist, dann bist du RTM und du solltest direkt auf CU23 und das neueste Security KB gehen. AFAIK war eine Migration von Exchange 2010 zu 2013 RTM nicht machbar und es wurde mindestens CU1 oder CU2(?) benötigt. Ansonsten wird das mit hoher Wahrscheinlichkeit am Autodiscover bzw. den virtuellen Verzeichnissen / Zertifikat liegen. Gruß Jan

Hi, wenn du das jetzt "eh anpackst", schau dir doch gleich einmal DFS-N (https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview) an. Dann musst du den Servernamen in Zukunft nicht mehr anpassen. ;) Generell wären deine bisherigen PowerShell Befehle / Code-Zeilen hilfreich. Ansonsten "Replace": https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_comparison_operators?view=powershell-7.1#replacement-operator https://devblogs.microsoft.com/scripting/use-powershell-to-replace-text-in-strings/ Gruß Jan

Hi, wenn die "User sich gegen das AD authentifizieren", dann _solltest_ du doch bereits CALs haben. Bzw. die Antwort lautet: Ja, du brauchst CALs. Gruß Jan

Hi, ist das zufällig ein "RDP double Hop" und da ist eine (DATEV) Smartcard involviert? -> https://www.datev-community.de/t5/Technisches-zu-Hardware/Seit-Installation-von-DATEV-14-0-Programmfehler-im-RDP-Client/m-p/181307#M2946 Gruß Jan

Hi, falls es dir hilft: Ich hatte einmal mit dem PayPal Käuferschutz zu tun und mir wurde im Fall von (coronabedingt) stornierten Flugtickets sehr schnell und unkompliziert alles Rückerstattet. Die Airline hat sich gar nicht gemeldet und die gesetzte Frist unkommentiert verstreichen lassen. Beim PP Käuferschutz hat es dann 16 Tage gedauert bis das Geld zurück war. "Leidensgenossen" haben da wesentlich länger gewartet bzw. mussten klagen. Gruß Jan

Bei mir funktioniert es lokal in der "gpedit.msc" in der "gpmc.msc" jedoch nicht. :)

Hi, das CU8 für Exchange Server 2019 und das CU19 für Exchange Server 2016 sind da: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-december-2020-quarterly-exchange-updates/ba-p/1976527 Ebenfalls wird für Exchange 2016 noch ein "final CU" CU20(?) für März 2021 angekündigt. Viel Erfolg beim Patchen & Gruß Jan

Ja. Wo soll denn das obige Script die Daten sonst hernehmen? Du könntest ja mal einfach so prüfen, was diese beiden Code-Zeilen tun: $LocalPath = "C:\install\mehgrab_ftp\images\PIR1" Get-ChildItem -Path $LocalPath -Filter *.jpg Je nachdem musst du halt noch den Pfad in "$LocalPath" anpassen. Das habe ich nur aus einem deiner Screenshots übernommen.

Hi, in PowerShell: $FTPServer = "<FTP Hostname>" $FTPUser = "<FTP User>" $FTPPass = "<FTP Pass>" $LocalPath = "C:\install\mehgrab_ftp\images\PIR1" $objWebClient = New-Object System.Net.WebClient $objWebClient.Credentials = New-Object System.Net.NetworkCredential($FTPUser, $FTPPass) $JPEGs = Get-ChildItem -Path $LocalPath -Filter *.jpg foreach($JPEG in $JPEGs){ Write-Output $("Lade `"{0}`" hoch..." -f $PictureFile.Name) $RemoteFile = New-Object System.Uri($("ftp://{0}/{1}" -f $FTPServer, $JPEG.Name)) $objWebClient.UploadFile($RemoteFile, $JPEG.FullName) } Sollte das nicht funktionieren, wäre ggfs. das noch ein (besserer) Ansatz: https://www.thomasmaurer.ch/2010/11/powershell-ftp-upload-and-download/ Beim FTPWebRequest lässt sich zumindest die Übertragung über SSL aktivieren. Gruß Jan P.S.: Generell scheinst du hier unverschlüsselt bzw. im Klartext per FTP zu übertragen. Das ist irgendwie genau so bescheiden wie Passwörter in Scripts. ;)

Beim DNS Suffix "intern" hätte ich Lancom im verdacht. Da könnte man es theoretisch sogar richtig(er) konfigurieren. ;)

Hi, dein Standardgateway bzw. der Router ist hier (am Server?) als DNS Server vermutlich fehl am Platz. Gleiches dürfte dann auch für DNS Server der Clients zutreffen. Gruß Jan

Well-known security identifiers in Windows operating systems: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/security-identifiers-in-windows So: https://abload.de/img/userhomew6j37.jpg Auf T:\Userhome hätte "Jeder" dann noch das Recht zum "Lesen, Schreiben, Ausführen" nur für den Ordner.

Das ist doch gar nicht notwendig. Der lizenzierte User (Mensch) kann/darf sich, sobald er eine Lizenz zugewiesen hat, mit jedem x-beliebigen (User) Account anmelden. Es werden immer (atmende) Menschen lizenziert und keine Accounts ("User"). Dafür würde ich einfach die Hälfte (oder auch nur eine einzige) auf RDS Lic01 und die andere auf Lic02 eintragen. Es gibt bei RDS User CALs keinen Mechanismus der hier irgendwas prüft/prüfen kann, solange eine einzige User CAL eingetragen ist. Die Lizenzen müssen halt einfach nur - in passender Anzahl - "im Schrank liegen".

Hi, wenn du "ein Script" zum ersten mal benötigst, würde ich jetzt nicht mit Batch anfangen. Schnapp dir direkt die PowerShell und den System.Net.Webclient oder greif zu 3rd Party wie bspw. dem WinSCP Assembly: https://winscp.net/eng/docs/library_powershell Gruß Jan P.S.: Es gibt Einfacheres zum Start in PowerShell. ;)

Schau dir doch einfach mal an, was du da an Pfaden nimmst und wo diese sich befinden: ... New-Item -Path $("{0}\BP_CutTraces" -f $ZIP.DirectoryName) -ItemType Directory ... Move-Item -Destination $("{0}\BP_CutTraces" -f $ZIP.DirectoryName) -Force ...

-Destination $("{0}\BP_CutTraces" -f $ZIP.DirectoryName) -Force wäre vermutlich einfacher. ;)

Die "Flip-Modelle" heißen doch heutzutage "foldable" und wurden bei meinem Kauf irgendwie komplett ausgeblendet. Da wäre aber auch auf den ersten Blick nur das Motorola Razr 5G interessant gewesen bis ich grade den Preis gesehen habe..

Ja, klar. Nimm die Zeile Get-ChildItem -Path $SourcePath -File -Filter *.zip und ergänze um ein "-Recurse". Danach kannst du vermutlich mit der obigen "Logik" weitermachen.

Ich habe mal folgendes aus allem hier rausinterpretiert: $SourcePath = "C:\Install\Test\Z_Messdaten" $DestPath = "C:\Install\Test\Z_Ausgabeordner" if(Test-Path -Path $SourcePath -PathType Container){ $ZIPFiles = Get-ChildItem -Path $SourcePath -File -Filter *.zip foreach($ZIPFile in $ZIPFiles){ $tempPath = $ZIPFile.BaseName.Split("_") $curDestPath = $("{0}\{1}-{2}" -f $DestPath, $tempPath[0], $tempPath[1]) if(-not (Test-Path -Path $curDestPath -PathType Container)){ New-Item -Path $curDestPath -ItemType Directory } Get-ChildItem -Path $("{0}\cuted\{1}" -f $ZIPFile.DirectoryName, $tempPath[1]) | Copy-Item -Destination $curDestPath -Recurse -Force } } else{ Write-Output "`"$SourcePath`" nicht vorhanden!" }

Dafür kennt PowerShell "Expand-Archive". Zip entpacken, das Benötigte "zusammen bauen" und dann sortieren / verschieben.