testperson

Wie gesagt auf nem "plain RDP" Terminalserver hätte ich da auch wenig Bock drauf. ;) Für den WVD gibt es bereits eine Teams Optimization (https://docs.microsoft.com/en-us/azure/virtual-desktop/teams-on-wvd). Hier müsste ich nur mal Lust haben, dass auf nem 2019er/2016er RDSH zu testen.. ;)

Naja, wir bzw. unsere Kunden machen das (zum Teil) allerdings ist hier in meinen Fällen immer Citrix CVAD im Spiel. An welcher Stelle hört der Spaß denn auf? Bei uns und unseren Kunden hört der Spaß leider grade im Bereich "Lizenzierung im shared Hosting" auf.. Ich finde den Post nicht, wo meine ich gesagt wurde bis Ende diesen Jahres. Auf die Schnelle habe ich nur die Ankündigung von der Ignite 2019 gefunden, wo man hoffte, innerhalb eines Jahres etwas Anlündigen zu können: https://techcommunity.microsoft.com/t5/exchange-team-blog/faqs-from-exchange-and-outlook-booths-at-2019-microsoft-ignite/ba-p/1053448 Hier (https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-server-2016-and-the-end-of-mainstream-support/ba-p/1574110) wird aber auch nur davon gesprochen, dass es keine Lösung gibt, bevor Exchange 2016 im Extended Support ist.

Ein Kompromiss der ggfs. "akzeptabel" ist, wäre den Kalender Button in Teams verschwinden zu lassen und Meetings nur in Outlook über das Teams Add-In zu planen. Dann brauchts kein Hybrid, bleibt aber unterm Strich unsupported. OT: Noch hat MS ja ca. 1,5 Monate Zeit die "Zukunft" ohne einen On-Prem Exchange zu benötigen anzukündigen. ;)

Wäre evtl. das OneDrive PowerShell Modul ein Ansatz auf der Serverseite die Fotos einzusammeln und auf dem Share abzulegen: https://www.sepago.de/blog/onedrive-powershell-module-added-support-for-onedrive-for-business/

Vergleich das doch mal mit diesem Dokument: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/config-firewall-for-ad-domains-and-trusts Zu den weiteren DNS Servern: Siehe @zahnis Antwort über mir. :)

Hi, wer und was sind denn ? Und die Firewalls dazwischen sind passend konfiguriert und blocken nichts? Gruß Jan

Hi, könntest du das nicht über ein SharePoint Teamwebsite machen und die Fotos in einer Dokumentbibliothek (Document library) ablegen? Gruß Jan

Hi, ich würde dir hier die PowerShell ans Herz legen: Mit Get-ChildItem holst du dir die Verzeichnisse unter D:\Backup Mit ForEach gehst du die Verzeichnisse nacheinander durch Mit Get-ChildItem holst du dir die Dateien, sortierst (Sort-Object) nach "LastWriteTime" und nimmst das letzte File (Select-Object -Last 1) Mit Compress-Archive erstellst du dir dein ZIP Gruß Jan P.S.: Ich würde auch den ersten Part ("Mit Zeitstempel wegkopieren") in PowerShell überführen.

Auch im Büro würde ich die Windows Firewall nicht abschalten sondern konfigurieren. ;)

Hi, kurz und schmerzlos: Get-ADComputer -Filter * -Properties Name, pwdLastSet | Select-Object Name, @{Name ="pwdLastSet";Expression={[datetime]::FromFileTime($_.pwdLastSet)}} | Sort-Object pwdLastSet Gruß Jan P.S.: Ist da irgendeine Form der Autokorrektur in die Hose gegangen oder verstehe ich den Zusammenhang mit dem Teddybär nicht?

Ja, das meine ich mit RDP-Feed. Allerdings würde ich das nicht "händisch verteilen", sondern per GPO (https://gpsearch.azurewebsites.net/#8113).

Hi, wenn du den RDS Feed nutzt, passiert das (AFAIK) automagisch. Ihr habt vermutlich händisch ein RDP File erstellt, signiert und dann auf die PCs verteilt. Das würde ich, sofern nichts dagegen spricht, einfach per RDS-Feed und GPO lösen lösen. Gruß Jan

Hi, losgelöst von der eigentlichen Frage, wo und warum möchtest du partitionieren? Gruß Jan

Was für ein NAS mit was für Platten ist denn das Ziel? Die Disks im NAS sind i.O. und da läuft im Hintergrund auch kein Rebuild oder irgendein bremsender Task?

Hi, hab den Thread nur überflogen, werfe aber auch mal das Backend und kein gebundenes Zertifikat ins Rennen. Zumindest hatten das bei uns "zuletzt" eine Hand voll Kunden. Gruß Jan

Hi, wie erstellst du denn das Backup also mit welchem Befehl? Läuft das Script auf dem Hyper-V Host oder in der VM selber? D.h.: Laufwerk C: bis G: sind eine virtuelle Festplatte (VHDX) mit entsprechenden Partitionen und H: ist eine eigene Disk (VHDX)? Gruß Jan

Hi Nils, danke für die Antwort. Ich hatte halt Hoffnung, da der Artikel im Dezember 2019 aktualisiert wurde und relativ klar nur auf 2016 abzielt. :) Ein wenig Recherche ergibt, dass es zumindest 2017 noch ein Bug war: https://social.technet.microsoft.com/Forums/azure/en-US/3453b83e-c719-4bdf-a3cb-cc32c5316dfe/change-configstorerootpath-value?forum=winserverhyperv Hier findet sich auch noch ein wenig zum Thema: https://blog.workinghardinit.work/2018/09/27/live-migration-fails-due-to-non-existent-sharedstoragepath-or-configstorerootpath/ Auch wenn der Anblick jedes Mal weh tut, werden wir wohl bis zur nächsten Hardwaregeneration damit leben. Strafe muss halt sein. :) Gruß Jan

Hi, in den Anwendungen wirst du die IP-Adressen der DNS eingetragen haben. "Firma.de" nutzt die Anwendung vermutlich zur LDAP Authentifizierung. Dann sollte folgendes auf dich zutreffen: https://social.technet.microsoft.com/wiki/contents/articles/33547.load-balancers-and-active-directory.aspx I.d.R. funktioniert das auch über entsprechende Loadbalancer. Ist aber, wie im Artikel beschrieben, seitens MS nicht supported. Gruß Jan

Hi, kurze Frage, ob ich mich bl*d anstelle oder der MS Artikel (https://support.microsoft.com/en-us/help/4488568/cannot-change-configstorerootpath-of-hyper-v-cluster-after-population) ein Update benötigt. Da ich in einem Hyper-V 2019 Cluster die gleiche Fehlermeldung erhalte, gilt "This behavior is by design in Windows Server 2016." wohl auch für 2019? Oder lässt sich der Pfad unter 2019 supported und ohne Downtime des Clusters oder ohne Migration in ein neues Cluster anpassen? Gruß Jan P.S.: Wir haben kein Problem allerdings sieht es echt nicht schön aus, dass da ein CSV weiterhin den alten Namen trägt. Da haben wir bei der Einrichtung der Cluster bzw. eher von Veeam leider nicht weit genug mitgedacht. :)

Danke für die Rückmeldung. D.h. der oder die DCs stehen in unterschiedlichen Netzen und eine Firewall filtert dort? Das wäre dann so eine Info, die man sich direkt im Ausgangspost wünschen würde. Denn es ist immer die Firewall (auch wenn die Netzwerker sagen, es ist alles in Ordnung). :)

Das ist die "Info", dass das Ziel nicht erreichbar ist.

Auch bei Roaming Profiles könnte man AppData\Local inkludieren. Alternativ zu Sunnys Weg kannst du auch in einer "gpmc.msc" einen Richtlinienergebnissatz erzeugen.

Hi, wenn die Clients jetzt in der neuen Domain sind, dann melde dich mit deinem neuen (Client-) Admin-User an dem PC an und verschiebe die Daten. Ansonsten sollte es einen lokalen Admin Account geben, mit dem du die PCs in die neue Domäne bekommst. Gruß Jan

Den "Heartbeat" hatte ich doch hier implementiert: https://www.mcseboard.de/topic/219017-dauer-ping-aber-nur-wechsel-erkennen/?do=findComment&comment=1410343 ;)

Dann müsstest du jetzt einmal "händisch" nachgucken, ob die Windows Firewall im derzeitigen Profil RDP eingehend erlaubt.