mulu
-
Gesamte Inhalte
73 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von mulu
-
-
vor 5 Minuten schrieb Dukel:
Du hast keine Produktiv Umgebung, nur eine Test Umgebung ;)
Per Se sowieso, wie jeder andere auch
Wer eine "echte" Test Umgebung hat, der hat den halt eine Pre-Test Umgebung
-
Gerade eben schrieb cj_berlin:
...und auch keinen Laptop mit SSD drin, und auch keine e-Mail-Adresse, zu der Du eine Azure Test-Subscription abschließen könntest?
damit könnte ich schon dienen, doch
Great idea. Ich werfe da einen Blick drauf, danke.
Gerade eben schrieb cj_berlin:"keine Testumgebung" ist kein Grund, in Produktion zu testen
Es sollte nur die Motivation sein, eine Testumgebung zu bekommen...
OK gut. Kann ja nicht widersprechen.
Danke nochmal!
-
vor 11 Minuten schrieb cj_berlin:
Naja, den Machine-Wide Installer herunterladen, paketieren und aufbringen... what else is there?
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
-
vor 2 Minuten schrieb cj_berlin:
Moin,
...aber welches Problem hast Du, bei dessen Lösung Du unterstützt werden möchtest? Gleich unter Deinem Link ist in den Docs doch https://docs.microsoft.com/de-de/microsoftteams/teams-on-rdp ...
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
-
Am 24.3.2021 um 11:49 schrieb mwiederkehr:
Ich würde das nicht über Office machen. Spezielle Tools dafür sind weniger fehleranfällig und wesentlich schneller.
Die Tools von GemBox sind super. Diese verwende ich für die serverseitige Erstellung / Konvertierung von Word- und Excel-Dokumenten. Es ist eine .NET-DLL, die lässt sich auch aus der PowerShell ansteuern. Die Lizenz ist pro Entwickler, ein damit entwickeltes Tool darf also weiterverteilt werden.
Günstiger ist der reaConverter, dafür lizenziert pro Rechner. Ich habe keine Erfahrung damit in Bezug auf Office-Formate, aber ein Kunde setzt den im grossen Stil für Bild- und Vektorkonvertierungen ein und ist sehr zufrieden damit. Er kann Ordner auf neue Dateien überwachen, so dass Du evtl. ganz ohne PowerShell auskommst.
Der reaConverter ist es. Gekauft, tut was mein Kunde braucht. Nochmal vielen Dank für den Tipp! 😀-
1
-
-
vor 5 Minuten schrieb mwiederkehr:
Ich würde das nicht über Office machen. Spezielle Tools dafür sind weniger fehleranfällig und wesentlich schneller.
Die Tools von GemBox sind super. Diese verwende ich für die serverseitige Erstellung / Konvertierung von Word- und Excel-Dokumenten. Es ist eine .NET-DLL, die lässt sich auch aus der PowerShell ansteuern. Die Lizenz ist pro Entwickler, ein damit entwickeltes Tool darf also weiterverteilt werden.
Günstiger ist der reaConverter, dafür lizenziert pro Rechner. Ich habe keine Erfahrung damit in Bezug auf Office-Formate, aber ein Kunde setzt den im grossen Stil für Bild- und Vektorkonvertierungen ein und ist sehr zufrieden damit. Er kann Ordner auf neue Dateien überwachen, so dass Du evtl. ganz ohne PowerShell auskommst.
Schau ich mir an, vielen Dank!
-
vor 2 Minuten schrieb BOfH_666:
Das ist dann ja vielleicht das Problem mit diesem Workaround - die Welt hat sich ja seit dem ein ganzes Stück weitergedreht. Dein OS ist aktueller und Dein Office ist aktueller - manche Technik ändert sich eben doch mit der Zeit.
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!
vor 8 Minuten schrieb mulu:Ich teste das mal noch auf einem anderen System und melde zurück.
Funktioniert auch auf einem anderen System nicht.
-
vor 25 Minuten schrieb BOfH_666:
Eventuell gibt es andere Tools, bei denen keine Office-Komponenten involviert sind, die sowas können - ich kenn aber leider keine. Eventuell lohnt eine entsprechende Suche auf StackOverflow.
Dort gibt es einen Workaround, der bei vielen funktioniert, den "Ogawa Hack". Nicht ganz aktuell das Ganze, zugegeben.
Ulkigerweise existiert dieser Ordner bei mir bereits, Rechte stimmen - ändert nichts.
-
vor 6 Minuten schrieb BOfH_666:
Das wird häufiger gefragt. Die Office-Programme wie Word oder Excel setzen eine interaktive Session voraus. Das wirst Du so nicht zuverlässig automatisiert bekommen.
Ich danke Dir vielmals. Keine Lösung, aber ich muss aufhören, den nichts existenten Fehler zu suchen, was nervenaufreibend ist.
vor 10 Minuten schrieb tesso:Meine Vermutung geht eher dahin das Berechtigungen fehlen. Unabhängig vom Benutzer braucht Zugriff für den Computer.
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
-
vor 10 Stunden schrieb testperson:
Rein aus Interesse: Welche Gründe haben gegen FSLogix gesprochen?
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.
vor 10 Stunden schrieb testperson:Falls nicht im Einsatz, wäre hier ggfs. AAD Sync sowie Single- / Seamless-Sign-On noch ein Ansatz.
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
-
vor 1 Stunde schrieb testperson:
Hi,
ich bin mir bei UPDs nicht 100% sicher, meine aber, du musst dort explizit "AppData\Local" bzw. zumindest "AppData\Local\Microsoft\Office\16.0\Licensing" aufnehmen.
Generell würde ich allerdings auch nichts (Neues) mehr mit UPDs machen sondern gleich auf FSLogix Profile Container setzen.
Gruß
Jan
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
-
vor einer Stunde schrieb testperson:
Hi,
ich bin mir bei UPDs nicht 100% sicher, meine aber, du musst dort explizit "AppData\Local" bzw. zumindest "AppData\Local\Microsoft\Office\16.0\Licensing" aufnehmen.
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
-
Gerade eben schrieb NorbertFe:
Genau. Wie man nur auf sowas kommen kann. ;)
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. -
vor 3 Minuten schrieb NorbertFe:
Korrekt. Ausnahme die erste Lizenz, wenn der Hypervisor (Windows) noch für andere Aufgaben bspw. Fileserver genutzt werden würde.
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
-
vor 2 Minuten schrieb Dukel:
Denkfehler: Der Vorzug ist die physikalische Instanz, nicht die 2 VM.
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
-
vor 27 Minuten schrieb testperson:
So ist es.
Dafür könntest du dich hier bedienen: https://www.mcseboard.de/topic/206136-microsoft-windows-server-2016-lizenzierungshilfe/
Danke nochmal, damit ist das auch geklärt.
-
Am 18.7.2020 um 05:58 schrieb lizenzdoc:
zum SVR >
den WIN-SVR sauber nach physischen COREs lizenzieren, beim Std aufpassen, dass es ev. mit der Anzahl der VMs auf dem Blech stimmt ( 1x Std erlaubt 2 VMs) braucht man 2 mehr,
das Blech mit 2 STD-Lizenzen lizenzieren usw. DC-Lizenz darf ja unlimitierte VMS auf dem lizenzierten Blech...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
-
Am 17.7.2020 um 17:36 schrieb testperson:
Wenn ich mich nicht irre, dann ist das was ich meine, genau der Fall für
das, sofern du die NAS mit Windows Server Standard lizenzierst und daher
dürfte das hier eine Rolle spielen. (Außer natürlich du lizenzierst die NAS, wie im OP angedacht, doch mit Datacenter, dann dürfte es Wurst sein.)
Verstanden. Good point.
Am 18.7.2020 um 05:58 schrieb lizenzdoc:Hi,
zu den CALs >
Alle USER, die real auf den TS-Dienst zugreifen sauber lizenzieren.
Device-CAL braucht man eigentlich nur, wenn z.B. an 1 Lager-PC 20 Lagerarbeiter den TS nutzen, da braucht man nur 1 RDS-CAL für den PC.
Eine CAL erlaubt den Zugriff auf alle unternehmensweiten SVR(z.B. WIN-SVR oder mehrere TS-Dienste), also bitte nicht doppelt/dreifach lizenzieren.Verstanden, danke!
Zitatzum SVR >
den WIN-SVR sauber nach physischen COREs lizenzieren, beim Std aufpassen, dass es ev. mit der Anzahl der VMs auf dem Blech stimmt ( 1x Std erlaubt 2 VMs) braucht man 2 mehr,
das Blech mit 2 STD-Lizenzen lizenzieren usw. DC-Lizenz darf ja unlimitierte VMS auf dem lizenzierten Blech...Verstanden!
Zitatdenke, ich hab alles, oder?
Ja, vielen Dank nochmal an der Stelle!
Grüße,
mulu
-
vor 4 Minuten schrieb testperson:
Hier gibt es AFAIK eine Lizenz-neu-zuweisungs-Regelung-im-Hardwareausfall-Fall. Da bin ich aber nicht tief genug im Thema, meine aber, du darfst nach Ausfall des Hyper-V Bleches die Lizenz dem NAS zuweisen. Zurück von NAS auf Hyper-V zugewiesen werden darf die Lizenz dann aber erst nach 90(?) Tagen. Das sollte dir aber jemand mit Ahnung erläutern.
OK, interessant :)
Wird hier keine Rolle spielen.ZitatBei dem Vorhaben könntest du evtl. überlegen, das mit zwei identischen Hyper-V Hosts anzugehen und das NAS nur als Backup Storage nutzen. Dann könnten, sofern von den Applikationen unterstützt, die Hyper-Vs ihre VMs auf den jeweils anderen als DR Maßnahme replizieren. Um hier allerdings mehr wie "Kommt drauf an" zu sagen, müsste man weitere Details bzw. entsprechende Anforderungen kennen.
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 :)
-
vor 4 Minuten schrieb testperson:
Mir würde spontan nur einfallen, dass du aufpassen müsstest, wenn du VMs von NAS <-> Hyper-V verschieben / replizieren wollen würdest, sofern das mit dem Hypervisor auf dem NAS machbar ist.
Guter Einwand, das soll aber nicht sein. Es geht mehr darum, einen zweiten DC zu haben. Es ist kein Verschieben oder replizieren geplant.
vor 6 Minuten schrieb testperson:Wenn auf dem NAS "nur" ein Domain Controller virtualisiert werden soll, würde ich ggfs. noch überlegen, das nicht zu tun und einen "Mini-Server" ggfs. direkt mit Standard Lizenz zu kaufen um dort den zweiten DC zu betreiben.
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!
Windows Server 2019 Terminalserver: Bereitstellung von Teams
in Virtualisierung
Geschrieben
Danke für den Hinweis!
Ich werde das alles genau studieren - bevor ich an die Testumgebung gehe