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

Danke für den Hinweis Jan! https://docs.microsoft.com/de-de/deployoffice/overview-shared-computer-activation Ich glaube, da bin ich jetzt richtig. Idealerweise sollte ich diesen Pfad jetzt mit in die Benutzerprofile schreiben. Ich werde das testen und rückmelden. Gruß, mulu

Hallo zusammen, Betriebsumgebung: Windows 10 Pro Clients Windows Server 2019 Server unter Hyper-V Windows Server 2019 Hypervisor Terminalserver mit zwei Sitzungshosts, einem RD-Verbindungsbroker, einem RD-Gateway, RD-Lizenzierung läuft auf einem getrennten Server RDS-Lizenzierung auf Benutzerbasis Benutzerprofile auf UPD-Basis auf einem Netzlaufwerk auf einem Fileserver 20 Benutzer Microsoft 365 E3 Pläne für das Office Verwendete Office-Anwendungen: Teams, Word, Excel, Outlook, Powerpoint Die verwendete Konfigurationsdatei für das Office Setup hänge ich an. Ausgangsszenario: Die Anwender melden sich per mstsc an der Sammlung an. Die Profile werden sauber erstellt, jede Änderung wird korrekt geschrieben. Lizenzierung läuft sauber und problemlos. Problemstellung: Bei jeder Anmeldung an der Sammlung hat das Profil die Aktivierung von Office vergessen. Office muss für jeden Benutzer durch Anmeldung mit seiner E-Mail Adresse und Kennwort aktiviert werden. Das Verhalten ist bei allen Benutzern gleich. Die Aktivierung funktioniert auch problemlos, nach Ab- und erneuter Anmeldung geht das aber jedes Mal von vorne los. Die Office-Apps melden, dass sie keine Verbindung herstellen können. Die Anmeldeinformationen in der klassischen Systemsteuerung sind und bleiben leer. Ich habe das in vier Screenshots dargestellt, siehe Anhänge. Natürlich ist bei Microsoft schon ein Support Ticket hierzu eröffnet, bislang konnte ich hier noch keine nützlichen Hinweise bekommen. Die erste Antwort vom Microsoft Support schlug vor, Outlook im safe-Modus zu starten. Das hat aber nicht funktioniert. Hat jemand vielleicht eine Idee, was ich falsch gemacht habe oder woran das hier hängt? Wenn mehr Informationen benötigt werden - bitte entsprechend kommentieren. Danke & Grüße, mulu Konfiguration.xml

Ich kenne die Thematik nur zu gut ;) Abgesehen von der Lizenzproblematik finde ich das auch technisch unsinnig. Das Blech will ich ja im Zweifel stressfrei ersetzen können, da bringen irgendwelche Dienste nur Ärger.

Ja, das ist mir klar, der Hypervisor macht Hyper-V und sonst überhaupt gar nix. Wäre ja auch irgendwie absurd, wenn der andere Dienste machen würde

Hallo Dukel, danke für den Hinweis, verstehe ich leider nicht. Meinst Du damit, dass eine WS 2019 Standard Lizenz immer 2 VMs lizenziert, unabhängig von dem Hypervisor? Heißt, der Vorzug ist die Berechtigung, einen Hypervisor mit der gleichen Lizenz zu betreiben, und dieser fällt bei der zweiten Lizenz dann weg? Grüße, mulu

Danke nochmal, damit ist das auch geklärt.

Hallo Franz, dazu noch eine einzige Frage: Ich hatte das bisher so gerechnet bez. Windows Server 2019 Standard: - die erste Lizenz lizenziert den Hypervisor und 2 VMS. - jede weitere Lizenz lizenziert nur EINE VM, da ja der Vorzug, zwei VMs auf einem Hypervisor mit nur einer Lizenz zu betreiben dann in Ermangelung eines Hypervisors wegfällt. Frage: Habe ich Dich richtig verstanden, dass ich quasi mit 2 Windows Server Standard Lizenzen auf einem Blech lizenziert VIER VMs betreiben darf usw.? Also mit 4 Lizenzen auf dem Blech auch 8 VMs? In dieser Konstellation rechnet sich die Datacenter Edition ja wesentlich später... Danke, Grüße usw. mulu

Verstanden. Good point. Verstanden, danke! Verstanden! Ja, vielen Dank nochmal an der Stelle! Grüße, mulu

OK, interessant :) Wird hier keine Rolle spielen. In einer idealen Welt... Natürlich wäre das so schöner. Scheitert hier aber am Budget. Die NAS kostet ein Drittel von so einem Hypervisor und kann dazu noch Backup und läuft mit einem Unix-Derivat. Viele Vorteile, der zweite Hypervisor wäre ja wirklich nur zur Steigerung der Verfügbarkeit gut, nicht etwa zur Datensicherheit. Da die NAS nicht mit Replikaten arbeitet kommt halt das letzte Backup hoch bei einem Hardware Ausfall, man kann ja sehr häufig sichern. Nochmal vielen Dank :)

Guter Einwand, das soll aber nicht sein. Es geht mehr darum, einen zweiten DC zu haben. Es ist kein Verschieben oder replizieren geplant. Auch das ist eine vernünftige Möglichkeit, die NAS ist ja hauptsächlich für die Datensicherungen da, darüber hinaus als Backup Hypervisor, die kann im Falle eines Hardwareausfalls die Gäste des Hypervisor booten, bis der "repariert" ist. Da bei diesem Projekt die Bestandsserver übrig bleiben ist das auf jeden Fall eine Überlegung wert, den zweiten DC physisch auf einem "alten Blech" zu betreiben. Danke für Deine Gedanken und Ideen!