cj_berlin

Meine erste Migration war nach Exchange 4.0. Aber ich würde meinen, 5.0 habe ich nie angefasst. 5.5 dann um so mehr.

Moin, "geht nicht" ist keine Fehlermeldung. Was geht denn genau nicht? OWA ist ja im Browser zu öffnen - wirft der Browser Zertifikatsfehler (welche)? Oder wirft Exchange Code 500?

Ja, es gab mal diese Bude, die sowas für XP angeboten hat, sie haben das gleiche geschrieben. Einige Kunden sind damit böse auf die Schnauze gefallen. Dein Kunde denkt wirklich, dass man in 2025 noch mit ASP einer per RDP ausgelieferten Win32-Anwendung Freunde gewinnen kann? Scary shit....

@Quirk18231 und was ist so falsch daran, den Dienst als SYSTEM zu starten? Wenn die fragliche Maschine kein Domain Controller ist, hat sie ja erst mal auch nur Authenticated User-Rechte auf anderen Systemen.

Welcher "ein Dienst" ist es denn? Der eine oder andere Dienst braucht *wirklich* Systemrechte, da reicht an Admin mit "Anmelden als Dienst" halt nicht.

Das ist ja dann nicht derselbe Name

Moin, wurde die Frage denn damals auch beantwortet? Ob Du das gleiche Lizenzpaket mehrfach einspielen kannst, wird technisch davon abhängen, wie Du es erworben hast. Wenn Du "nur" eine Microsoft-typische Lizenznummer hast, muss sie aktiviert werden, damit kannst Du nicht das komplette Päckchen mehrfach verwenden. Wenn Du eine "Contract ID" hast, kannst Du sie auch mehrfach eintragen. ABER. Bei User-CALs hört der Lizenzserver mit der Ausgabe ja nicht auf, wenn der Pool ausgeschöpft ist, sondern geht einfach drüber. Daher kannst Du das Paket auch aufteilen, und für die Springer wird auch gesorgt sein. Cross-Forest RDS-CALs sind möglich, die Vertrauensstellungen müssen dann aber beidseitig sein, und super zuverlässig ist es auch nicht. VPN-Ausfälle hingegen sind normalerweise verschmerzbar. Würde ich in dem Szenario dennoch nicht empfehlen.

Genau. Und darunter die Handynummer von Franz. Und auch, dass niemand die Zahlen im RDS-Lizenzmanager auch nur versuchen sollte zu interpretieren.

Die, die NetBIOS über TCP/IP noch aus Gründen einsetzen müssen, weil eine 20 Millionen teuere Maschine noch 10 Jahre abgeschrieben werden muss. Aber an SRP ist nix wirklich falsch. Es ist halt super unflexibel, und deswegen fanden wir alle damals AppLocker so geil. Aber, wie ich oben schon schrub, in einfachen Szenarien ist es etwas, das einfach funktioniert. Wie hast Du dein SRP denn konfiguriert?

Soll ich mal ausgraben, wie lange WINS schon deprecated ist?

Weil SRP für einfache Use Cases zuverlässiger ist und von keinem Service abhängt, der angehalten werden kann (und überhaupt erst gestartet werden muss)?

Moin, hast Du auch eine Security-Filterung auf dem GP-Objekt? Sie muss den Computer zulassen, an dem sich der Benutzer anmeldet. Ansonsten, wenn Du "Angewendete Gruppenrichtlinien" siehst, siehst Du ja auch "Abgelehnte Gruppenrichtlinien", mit Begründung, warum sie abgelehnt wurden. Wenn Du sie weder da noch dort siehst, hat sich das Objekt, die Platzierung des Users, oder die Verknüpferei vielleicht nicht repliziert...

Da sich bisher niemand bemüßigt gefühlt hat, danke ich hiermit herzlich allen Sysadmins da draußen, die unsere Welt am Laufen halten! Macht weiter so, Jungs und Mädels, fühlt euch umarmt, falls ihr auf sowas steht!

Das gerade nicht, aber sie stoppen auch nicht das Ausstellen von neuen CALs, wenn der Pool aufgebraucht ist

Moin, ich werfe mal was anderes rein: ist es sichergestellt, dass Deine Linux-Endgeräte die ausgestellte RDS-CAL ordentlich speichern können? Technologisch sind nämlich User und Device CALs vollkommen unterschiedlich: Die User CALs sind im User-Objekt im AD gespeichert, Device CALs hingegen *auf dem Device selbst*. Und gerade bei Thin Clients kann es vorkommen, dass sie beim Reboot, beim Image-Update oder bei anderen Vorgängen die Device-CAL "vergessen". Kann der Lizenzserver keine neue ausstellen, ist keine RDS-Verbindung möglich. Somit wirst Du bei 10 Geräten nur sehr selten mit 10 Device CALs auskommen. Klar, 120 User CALs kosten erst einmal mehr als 10 Device CALs. Aber Deine Zeit, Ressourcen für eine zusätzliche Session Collection usw. usw. sind doch auch nicht kostenlos.

Ja, genau.

mit "im AD" meinst Du das mail-Attribut oder den Eintrag in proxyAddresses wo SMTP: großgeschrieben ist?

Moin, ja, wenn Du das in der Remote-PSSession machst, ist der auf die Konsole ausgegebener Text ein Text. In der Exchange Management Shell findet eine Konvertierung statt, die das Sortieren erlaubt. Hier eine Anregung: $val = "802.2 KB (821,428 bytes)" if ($val -match ".*\((?<val>[\,\d]+)\sbytes\)") { $Matches['val'] -replace ',' }

@lizenzdoc Ich hätte das gerne wenigstens EINMAL IM LEBEN so von einem Auditor gehört. Es war IMMER "Fähigkeit zu starten ohne vorher zusätzliche technische Maßnahmen ergreifen zu müssen". Vielleicht waren sie alle Oracle-verseucht, was weiß ich. Als Alternative wurde oft ein SAM-Produkt mit lückenlosem Software-Metering ins Gespräch gebracht, worauf dann natürlich wieder Betriebsräte allergisch reagieren. Als Techniker leuchtet es mir auch total ein - das Unternehmen unterschreibt, dass von den vorhandenen 10.000 Endgeräten nur 2.500 Office-Programme nutzen, obwohl von allen 10.000 aus eine Terminalserver-Farm mit installiertem Office erreichbar ist. Wie kann diese Aussage aber auf nichtpersistenten Terminalservern validiert werden? Vielleicht waren's ja nur 500 Geräte und es gibt Geld zurück?

Ja, aber wie einem Kunden von mir von dem Auditor erklärt wurde, ist "install" im Falle der Zweitnutzung wörtlich zu verstehen. Und dann - beide Fälle waren dort relevant - muss der "Primary User" auch bestimmbar sein. Sprich, wenn Du einen Workstation-Pool und einen Notebook-Pool hast, wird es mit der Zweitnutzung eng. Aber solche Feinheiten sind was für den @lizenzdoc, ich bin froh, damit nichts mehr zu tun zu haben

Moin, ja, alle Office-Versionen, die nicht auf 365 enden, sind per-device lizenziert. Damit ist mit einer Lizenz die lokale Installation auf einem physikalischen Endgerät + Remote-Zugriff von diesem Endgerät auf alle Office-Instanzen der gleichen Version, die sich innerhalb des Unternehmens (im lizenzrechtlichen Sinne, da können auch verbundene Unternehmen darunter fallen) befinden. Also alle Terminalserver, VDI, Zugriff auf physische Workstation etc. Aber Obacht! Wenn ein Mitarbeiter mal eben schnell von seinem iPad auf den Terminalserver zugreift, benötigt das iPad EBENFALLS eine Office-Lizenz, auch wenn Office dort lokal nicht installiert werden kann (in dieser Version). Und, ganz wichtig: Nicht die tatsächliche Nutzung von Office ist beim Audit entscheidend, sondern die Möglichkeit einer Nutzung.

Zertifikate? TLS Inspection auf der Firewall? TLS Versionen in GPO ein-/ausgeschaltet?

Moin, was bekommst Du von Invoke-RestMethod -Uri "https://outlook.office365.com/autodiscover/autodiscover.json/v1.0/<user>@<domain>?Protocol=EWS" zurück? Vom Domänen-Client, <user>@<domain> durch die Mail-Adresse des angemeldeten Users ersetzt.

Das ist fast korrekt. Aber die Packages werden nachinstalliert, wenn sie provisioniert sind. Somit sind User, bei denen Remove-AppXPackage gemacht wurde, im Sinne der Provisioned Packages quasi "neu". Das ist aber keine Universalwahrheit, sondern von Paket zu Paket unterschiedlich. Manche respektieren das einmalige Entfernen, andere brauchen die Keule.

Du musst noch die AppxProvisionedPackages entfernen, damit sie nicht wieder auftauchen.