testperson

Ich vermute, dass Split-Tunneling hier nicht hilft, da der VPN Tunnel getrennt wird sobald das WLAN sich verbindet. Das klingt so, als würde die Notebook WLAN Schnittstelle beim Verbinden mit dem Drucker ein Gateway bekommen und der AnyConnect will dieses dann bevorzugen. Beim Lancom Advanced VPN Client bzw. dann vermutlich auch beim "NCP Client", kann man im VPN Profil des Clients ein Verbindungsmedium festlegen und bspw. mit den Mobilfunkdaten des Providers ausstatten. Das würde dann aber vermutlich je ein VPN Profil für Mobilfunk und eins für WLAN im Home Office benötigen. Warum muss es denn unbedingt WLAN sein? Für mich ist das ohne weitere Details zu kennen eine Helpdesk ABM. Wenn du scripten möchtest, wäre das evtl. ein Ansatz: Auf WLAN Verbindung mit dem Drucker prüfen (Sofern hier DHCP im Spiel ist und ein Gateway auf dem Interface ankommt, die IP Konfiguration auslesen) (Den Adapter auf statische IP Konfiguration ohne Gateway umkonfigurieren) VPN Verbindung aufbauen Bis zum Trennen des VPNs / Logoff / Shutdown warten WLAN Interface zurück auf DHCP konfigurieren Meine Meinung bleibt weiterhin: Drucker per USB anstecken -> Glücklich sein. Mal davon abgesehen, dass das in meinen Augen per WLAN eine wackelige Angelegenheit wird hätte ich mit den Stichworten "Drucker" und "WLAN" auch noch Bedenken in Richtung "Security".

Hi, ich kann auch nur zu SetACL, icacls oder SubInACL raten. Ich habe nach mehreren Anläufen sämtliche Versuche in PowerShell aufgegeben. Das "Problem" kann da aber auch an mir liegen. ;) Gruß Jan

Weil der Hyper-V Hosts nichts neben Virtualisierung / Verwaltung dieser / Backup ausführen darf ohne eine Lizenz zu benötigen. Wenn der Host nur zu diesem Zweck dient, darfst du zwei Windows vOSE mit der zugewiesenen Lizenz betreiben. Wenn mich nicht alles täuscht geht das schon. Allerdings muss man sich bzw. den Essentials ganz schön verbiegen. Ob das dann noch lizenzkonform ist, steht auch auf einem anderen Blatt. Das ist vollkommen korrekt. Hier müsste man sich aber sicherlich mal an einen Tisch setzen, die Anforderungen zusammentragen und dann sollte auch "Augenmaß" dabei sein. :)

Nein. Zumal der dann auch eine Lizenz benötigen würde bzw. dann eben keine zwei VMs mehr betrieben werden dürften. Für Filesharing habe ich gehört, das soll sogar mit Linux machbar sein. ;)

Hi, du hast ja hier nicht nur das "Problem" Drucker sondern auch noch WLAN. Warum die Drucker im Außendienst nicht einfach per USB anstöpseln? Ein anderer Ansatz könnte noch sein, mobile WLAN Router mit der SIM Karte zu nutzen und Drucker + Notebook an diese Hotspots zu verbinden. Ein ganz anderer Ansatz, warum überhaupt unterwegs drucken? "Save paper – think, before you print" :-P Gruß Jan

Hi, "solche Umgebungen" lassen sich durchaus auch "in der Cloud" betreiben bzw. könnten sicherlich Teile der Anwendungen aus "Clouds" bezogen werden. Gruß Jan P.S.: Team Hyper-V-Hosts-gehören-in-die-Domäne

Hi, wenn ich dich richtig verstehe klingt das nach der Notwendigkeit von Split-DNS. Ansonsten müsstest du die an der RDS-Bereitstellung involvierte Infrastruktur einmal etwas ausführlicher skizzieren. Gruß Jan

Ist das nicht weiterhin der Windows Server 2019 1809 allerdings mit den bereits integrierten Windows Updates bis April 2020? Zumindest würde ich das bei mir so aus dem VLSC herauslesen: Ist das wie bei Win 10 z.B. neu, dass beim Erscheinen eines neuen Builds (2004) der Build-1 (1909) auf den jeweiligen Patchday geupdated wird?

Ich bin mir bei beiden Werten nicht sicher. Wenn jemand den "Hidden" Part entsorgt hat sofern er da war, wäre ja auch ein Löschen des Versions-Filterungs-ILT in der GUI machbar gewesen. In der Datei kann man das ja so oder so löschen. Daher mein Tipp, sofern an der korrekten Stelle gesucht wird, da hat jemand einfach beide Werte im File entsorgt.

Hi, auf die Schnelle habe ich nur zwei Links gefunden, die auf "Windows Server" generell eingehen: https://www.comconsult.com/dominanz-usa-softwarehersteller/ https://www.wikiwand.com/de/Microsoft Wie verlässlich und hilfreich das ist, steht sicherlich auf einem anderen Blatt. Gruß Jan

Hi, wenn du das zu Ende zitierst, gibt es da noch einen weiteren Satz (https://www.datenschutzkonferenz-online.de/media/oh/20200526_orientierungshilfe_e_mail_verschluesselung.pdf): Ich gehe allerdings auch davon aus, dass Lieschen Müller ebenfalls keine Ahnung hat welche Mailserver des Providers welche IP Adressen haben. Ebenfalls findet sich im Dokument zu "DNSSEC" noch: Trifft das denn überhaupt zu? Wurde überhaupt von "irgendjemandem" festgelegt was ein "... hohes Risiko für die Rechte und Freiheiten ..." darstellt? Ebenfalls lässt das zuletzt zitierte ja auch noch Luft nach unten. Wäre ich jetzt Lieschen Müller, hätte ich gar kein Interesse eine solche Angelegenheit per Mail zu bekommen. Vermutlich würde ich diese Information nicht mal am Telefon entgegennehmen wollen. ;) Eine (traurige) Alternative: De-Mail. Zumal man seine Mandanten aus Privatpersonen ebenfalls schlecht zu De-Mail zwingen kann. Gruß Jan

Hi, das sollte sich in PowerShell nachscripten lassen. Das Script kann dann täglich per Task gestartet werden und informieren. Alternativ wäre halt eine "richtige" Monitoring Lösung (Zabbix, PRTG, Nagios, Icinga, CheckMK und wie Sie alle heißen) ein Ansatz. Je nachdem wäre hier auch eine Cloud Lösung (Kaseya, Solarwinds, ...) sinnvoll. Gruß Jan

Einen kleinen Ansatz in PowerShell hätte ich hier schonmal vorbereitet: https://www.mcseboard.de/topic/218102-gpo-wird-erst-nach-gpupdate-angewandt/?do=findComment&comment=1401640

Hi, ich würde am "$smtpserver" einmal in die SMTP Logs schauen, ob da im Fehlerfall etwas zu sehen ist. Wenn dort das Logging aktiv und die Retention hoch genug ist, solltest du da auch rückwirkend noch Infos finden können. Gruß Jan

Der nagt aber auch an Exchange und da käme dann direkt die Frage auf, ob es tatsächlich einen On-Prem Exchange braucht. "Die Zeit" wäre hier Exchange online. Um mit der Zeit zu gehen bräuchtest du von den o.g. Server vor Ort eigentlich "nur" DC und ADFS sowie ggfs. den Printserver und Mailstore. Der Rest lässt sich als Service aus der Cloud beziehen. Ich zitiere dich einmal, da das auch hier gilt:

Dann solltest du deine GPOs anpassen, da hättest du zwei Möglichkeiten: In neuem GPO: Loopbackverarbeitungsmodus "Replace" für die RDSHs FSLogix Konfiguration für die RDSHs Entfernen der lokalen Policy/ies Im bestehenden Profil GPO: Anpassen der Sicherheitsfilterung Den RDSHs das Lesen verweigern Das Lesen der "Authentifizierten Benutzer" entfernen und einer Gruppe mit deinen Client-Computern das Lesen erlauben Neues GPO für FSLogix Konfiguration für die RDSHs Entfernen der lokalen Policy/ies Was für dich besser / einfacher ist, ist schwer zu sagen, da müsste man dein AD Design für sehen bzw. kennen. Laufen bei euch nur bestimmte Applikationen auf den Terminalservern und ein Teil der Anwendungen auf den lokalen Clients oder wozu benötigen die User lokal immer ihr Profil? Generell würde ich mir einen Plan machen, die Roaming Profiles auf den Clients zu entsorgen.

Wo hast du denn welche Roaming Profiles konfiguriert? Und warum benötigst du am lokalen Client Roaming Profiles?

Du könntest damit mal an Thomas Krenn rantreten. Evtl. haben die ja Erfahrungen damit oder äußern sich dazu.

Hi, das sollte eigentlich automatisch passieren. Die Policies bzgl. FSLogix sollten in der Theorie und nach korrekter Konfiguration nur auf den RDSHs / VDIs angewendet werden. Ebenfalls sollten die benötigten FSLogix Komponenten nur auf den RDSHs installiert sein. Somit sollten die lokalen Clients eigentlich gar nicht erst auf die Idee kommen ein FSLogix Profil zu laden, da unter anderem die benötigten Gruppen nicht vorhanden sind. Gruß Jan

Ohne weitere Anforderungen zu kennen würde ich sagen, dass es in dem Szenario maximal "RDP" gibt, das von schnellem Storage profitieren könnte. Welche Anwendungen laufen denn später auf den RDSHs? Generell würde ich hier das Geld lieber in schnellere CPUs investieren, da Storage selten der begrenzende Faktor ist.

Hi, ich habe keine direkte oder hilfreiche Antwort, würde aber fragen, was du denn am Ende erreichen willst also was soll der Server später wofür bereitstellen? Eine weitere Frage wäre, brauchst du am Ende auch "so viel Disk / Cache Leistung"? Gruß Jan

Guten Morgen Franz, vielen Dank für die Antwort. CSP Tier 1 würde dann neben dem geforderten Umsatz noch ganz andere Herausforderungen auf den Tisch bringen. Als Alternative käme mir da momentan Azure, Umstellung auf Housing oder evtl. ein passender RZ Anbieter in den Sinn. Hier noch ein Edit: Da sich Teams leider auch im Benutzerkontext installieren lässt und somit in unserem Fall erstmal an uns als Hoster vorbeiläuft, wären wir in diesem Fall ohnehin nicht compliant? Dann könnte ich der obigen, für uns eher negativen, Aussagen doch noch was positives abgewinnen, da wir dann nicht an AppLocker vorbei kämen. Gruß Jan

Hi, du kannst dir mit Get-ADUser alle User zusammensuchen und dann durch eine foreach-Schleife jagen und mittels "Replace" den neuen DisplayName setzen (Set-ADUser). In grob: $Users = Get-ADUser -Filter * -SearchBase $("OU=<deine>;OU=<BenutzerOU>,DC=<Domain>,DC=<TLD>") -Properties DisplayName # foreach Set-ADUser $User -DisplayName $User.DisplayName.Replace("alter Wert","neuer Wert") Je nach Aufbau solltest du das ggfs. noch prüfen, nicht das der "alte Wert" an weiteren Stellen im DisplayName auftaucht und dort auch ersetzt wird. "Notfalls" kannst du dir alt und neu auch erst in eine CSV exportieren und dort händisch ggfs. nacharbeiten. Gruß Jan

Hi, dann würde ich die Updates auch entsprechend über den WSUS bereitstellen. Wenn das einmalig ist oder nur selten zum Einsatz kommen soll, wäre halt auch PowerShell ein Ansatz. In ganz grob: $Package = Get-Package -ProviderName MSI | where { $_.Name -eq "<dein Paket>" } # ggfs. die Versionsprüfung mittels [long]$Package.Version.Replace(".","") wandeln und mittels -lt prüfen, damit nicht neuere Versionen mit einer alten überschrieben werden if($Package.Version -ne "<neue Version>"{ Uninstall-Package $Package # ggfs. auch per msiexec.exe deinstallieren $InstallProc = Start-Process -FilePath $($env:windir + "\system32\msiexec.exe") -ArgumentList $("/i <Pfad zum MSI> /qb- <ggfs. Parameter> /L*v <Pfad zum Log> < ggfs. /norestart>") -PassThru -Wait do{ #Warten... Start-Sleep -Seconds 5 }until($InstallProc.HasExited) # An dieser Stelle bspw. mit Switch-Case den $InstallProc.ExitCode auswerten und reagiern und/oder das Logfile nach Erfolg / Misserfolg / Reboot durchforsten } Das lässt sich dann per StartUp-Script und/oder Aufgabe zum / auf den Client bringen und ausführen. Mit ein wenig Kreativität lässt sich die neue Version bspw. zum Paket in eine CSV legen und somit hättest du eine "kleine Softwareverteilung". Generell sollte natürlich noch ein wenig (besser mehr) Logging ins Script und bspw. auch erfasst werden, falls ein Client bereits aktuell ist. Gruß Jan

Du könntest an wöchentlich oder monatlich präventiv du Umlaufprotokollierung aktivieren, DBs abhängen, anhängen, Umlaufprotokollierung deaktivieren, DBs abhängen und wieder anhängen. ;) Alternativ die an Exchange beteiligten Volumes auf 10%-20% freien Speicher monitoren oder allerspätestens bei diesen Events (https://docs.microsoft.com/en-us/exchange/mail-flow/back-pressure?view=exchserver-2019#back-pressure-logging-information) eingreifen.