mulu

Danke für den Hinweis! Ich werde das alles genau studieren - bevor ich an die Testumgebung gehe

Per Se sowieso, wie jeder andere auch Wer eine "echte" Test Umgebung hat, der hat den halt eine Pre-Test Umgebung

damit könnte ich schon dienen, doch Great idea. Ich werfe da einen Blick drauf, danke. OK gut. Kann ja nicht widersprechen. Danke nochmal!

Genau darum geht es mir, habe hier leider keine Testumgebung und keine Möglichkeit, zu testen. Sollte also auf Anhieb klappen. Danke für den Link, sehe ich mir genau an. Gruß, mulu

Sorry, habe mich missverständlich ausgedrückt. Es geht um die Installation der Anwendung, nicht um die Bereitstellung im Sinne der Konfiguration - das ist in dem Artikel ja gut beschrieben. Gruß, mulu

Hallo werte Gemeinde, ich bin auch der Suche nach einem Howto für die Bereitstellung von der Teams Desktop App auf einem Windows Terminal Server. Szenario(siehe auch Screenshot): Virtualisierte Windows Server 2019 Datacenter Terminalserver unter Hyper-V Eine Sammlung mit 2 WTS Office 365 E3 für alle Benutzer CAL Lizenzierung auf Benutzerbasis Bereits geprüft: https://docs.microsoft.com/de-de/microsoftteams/teams-for-vdi Werde daraus aber nicht schlau. Vielleicht hat das ja jemand in letzter Zeit umgesetzt und kann hier helfen? Danke für jeden Hinweis vorab, auch Kritik lese ich immer gerne. mulu

Der reaConverter ist es. Gekauft, tut was mein Kunde braucht. Nochmal vielen Dank für den Tipp! 😀

Schau ich mir an, vielen Dank!

Ja, mag sein. Ich teste das mal noch auf einem anderen System und melde zurück. Du hast mich auf jeden Fall in der Sache massiv weitergebracht, dafür noch einmal vielen Dank! Funktioniert auch auf einem anderen System nicht.

Dort gibt es einen Workaround, der bei vielen funktioniert, den "Ogawa Hack". Nicht ganz aktuell das Ganze, zugegeben. Ogawa Hack on stackoverflow Ulkigerweise existiert dieser Ordner bei mir bereits, Rechte stimmen - ändert nichts.

Ich danke Dir vielmals. Keine Lösung, aber ich muss aufhören, den nichts existenten Fehler zu suchen, was nervenaufreibend ist. Vielen Dank für den Ansatz!

Hallo zusammen, Arbeitsumgebung: Windows 10 Professional V20H2 x64 DELL Optiplex 3070 (i5/8GB/SSD) Kleine Active Directory Umgebung, Benutzer hat lokale Adminrechte und auf alle beteiligten Pfade Schreibrechte. Ich möchte Worddokumente (*.docx) in PDF-Dateien konvertieren. Hierzu habe ich ein Script geschrieben, das tut was es soll, solange man es interaktiv startet. $path = 'C:\ESD\*' $wd = New-Object -ComObject Word.Application Get-ChildItem -Path $path -Include *.docx | ForEach-Object { $doc = $wd.Documents.Open($_.Fullname) $pdf = $_.FullName -replace $_.Extension, '.pdf' $doc.ExportAsFixedFormat($pdf,17,$false,1,3,1,1,0,$false, $false,0,$false, $true) $doc.Close() } $wd.Quit() Die Dokumente liegen in diesem Beispiel in C:\ESD, das Script in C:\ESD\Dokumentation. Die PDF-Dateien sollen in C:\ESD abgelegt werden. Funktioniert über diverse Aufrufe, z.B. über die Powershell mit einem Aufruf .\pdf_converter.ps1 oder auch mit Rechtsklick und "Mit Powershell ausführen". Über die Aufgabenplanung bekomme ich es nicht zum Laufen. Der Task wird gestartet und erfolgreich ausgeführt, Ergebnis gibt es aber keines. Soll heißen, die Dateien werden nicht konvertiert. Parameter in der Aufgabenplanung: - Ausführung erfolgt über einen berechtigten Benutzer aus dem AD - Unabhängig von der Benutzeranmeldung ausführen - Mit höchsten Privilegien ausführen - Konfigurieren für: Windows 10 Trigger: Täglich um 10:01 Uhr ausführen Aktionen: - Programm starten: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe - Argumente hinzufügen: -ExecutionPolicy Bypass -File c:\esd\Dokumentation\pdf_converter.ps1, Pfad alternativ in Anführungszeichen - ändert nichts. - Starten in: C:\ESD\Doumentation, auch schon in Anführungszeichen probiert, auch schon ohne probiert. Ändert nichts. Bei manuellem Ausführen über die Aufgabenplanung wird eine erfolgreiche Ausführung protokolliert: Die Aufgabenplanung hat die Instanz "{40350e99-4130-4c9a-9324-20bcf7807b18}" der Aufgabe "\PDFConverter" für den Benutzer "domain\benutzer" erfolgreich fertig gestellt. Ich habe andere Powershell-Skripte, die über die Aufgabenplanung ohne Probleme laufen mit den gleichen Parametern und Verzeichnissen. Diese Scripte rufen aber keine Programme auf, sondern kopieren im Vorfeld die Dateien in das Verzeichnis "C:\ESD". Beispiel für das Script: $srcPath = 'C:\ESD\Vorlagen\' $destPath = 'C:\ESD\' # target files where LastWriteTime >= 960 minutes "ago" $age = (Get-Date).AddMinutes(-960) #Write-Output "$age" $newFiles = Get-ChildItem $srcPath | Where-Object { $_.LastWriteTime -ge $age } #Write-Output "$newFiles" foreach ($newFile in $newFiles) { #Write-Output "Copying $newFile to $destPath" Copy-Item $newFile.FullName -Destination "$($destPath)$($newFile)" } Vielleicht klingelt es ja bei einem Leser an der einen oder anderen Stelle. Ich kann nur vermuten, dass der Aufruf der Word Anwendung auf diesem Weg nicht funktioniert. Danke für Eure Aufmerksamkeit vorab! mulu

Hallo Jan, zunächst der aufwändigere Setup Prozess, ich hatte hier leider zeitlich enormen Druck bei der Umsetzung. Meine fehlende Erfahrung im Umgang, der Ursprung von FSLogix. Alles keine guten Argumente, aber eben die Realität in dem Fall. Definitiv. Die Umgebung ist jetzt "erstmal" so online, SSO und AAD Sync würden die Benutzererfahrung sicher noch verbessern. Nochmal vielen Dank für Deine Hilfe! Grüße, mulu

Problem gelöst, danke an Jan! Lösung siehe mein letzter Post. Wenn das gesamte Profil in die UPD geschrieben wird funktioniert auch die Aktivierung wie erwartet. Grüße, mulu

Habe jetzt die Ausschlüsse in der Sammlungskonfiguration der WTS deaktiviert. Das Profil wird jetzt vollständig in die UPD geschrieben. Teil des Themas damit erledigt, es muss noch Teams jedes Mal mit dem Kennwort bestätigt werden, Office muss nicht mehr aktiviert werden. Vielen Dank für den Hinweis! Und was die FSLogix Container angeht - habe ich mir im Vorfeld angeschaut und mich dagegen entschieden. Grüße, mulu