Alle Aktivitäten

Sehr gute Frage, wir hatten für 4-6 Admins jeweils einzelne Server. Im Grunde ist die TS Idee aber deutlich besser und lizenztechnisch, würde ich vermutlich auch zum Pack tendieren und gut ist 👍

Na dann get-exchangecertificate :p achne das ging ja nicht in diesem Fall 😂

Moin, Klingt plausibel. Also, eigentlich klingt das total beh*mmert, aber wenn man schon seit fast 25 Jahren Automatisierung von AD-Prozessen beobachtet, dann ist es eben plausibel. Nebenbei willst du uns aber sagen, dass das Quest-Tool diese Probleme nicht selbst behandelt, ja? Auch das würde ich in Verbindung mit dem Hersteller nicht zum ersten Mal hören. Was hatten wir vor 15 Jahren für einen Aufwand, hinter den Lücken im Migrator herzuscripten. (Aber das nur am Rande.) Danke für den Einblick. Gruß, Nils

Jaaaa Oder sooo Menno, hab frei...

Get-ChildItem -Path Cert:\LocalMachine\My ;)

Fürs nächste mal einfach certlm.msc ;) viel schneller.

Die Idee von Jan war besser…

ja, das war´s - das Binding zum Zertifikat musste hergestellt werden... DANKE!

Guck mal in die das Management der lokalen Zertifikatstelle eine mmc aufmachen (Deutsch) Datei - Snapin hinzufügen - linke Seite Zertifikate - hinzufügen - Computerkonto - Fertig stellen - lokaler Computer - Fertig stellen OK dort solltest m.E. unter eigene Zertifikate die lokalen Exchange Zertifikate finden (kann ich nicht gucken, alles aus dem Kopf…) Da könnte man auch das lokale interne Zertifikat erneuern An einem cmd als Admin danach iisreset und du solltest wieder drauf kommen Laufen denn alle relevanten Dienste? (Taskmanager bzw. Servermanager)

Ok Wir haben ein Drittprodukt (Quest GPOAdmin), das GPOs über Domänengrenzen synchronisieren kann. Ein in der Quelldomäne per GPMC-API erstelltes GPO-Backup im ZIP-Format wird dabei zum Zielserver übertragen. Dort wird von der Ziel-GPO eine tempoärer Kopie erzeugt und dann das entpackte Zip (wieder per GPMC-API) in diese Kopie importiert. Danach wird (wieder GPMC-API) davon ein Backup estellt, die temporäre Kopie gelöscht und das aktuelle Backup in die ursprüngliche "produktive" GPO importiert (noch mal GPMC-API). (Klingt aufwändig mit der temporären Kopie und dem vielen Import/Export, das hängt mit den verfügbaren Workflows zusammen - man kann nicht nur "immediate deployment" machen, sondern auch erst mal "stagen"- das sprengt den Rahmen hier aber.) Das arbeitet also mit ein wenig Zip/Copy, der Rest ist GPMC-API nativ. Dabei fällt der Import in die temporäre Kopie regelmäßig auf die Nase, wenn der jeweilige Server mehr als einen DC sieht. In AD wird das GPC-Objekt immer auf dem PDC angelegt (das kriegt das GPMC-API noch hin). Der GPT-Sysvol-Ordner entsteht dabei ebenfalls "initial" - aber nicht auf dem PDC, sondern "irgendwo". Der folgende Import per GPMC-API greift AD-seitig auch nur auf den PDC zu und findet den GPC-Container. Der Dateiimport in den GPT-Sysvol-Ordner läuft über DFSR aber wieder gegen "irgendeinen" DC. Und DFSR hat auch innerhalb einer Site Latenzen -> Sysvol-Ordner nicht vorhanden -> "Path not found". Macht man das von Hand, ist es i.d.R. kein Problem, weil man von Hand nicht so schnell klicken kann (DFSR-Latenzen intra-site sind im Sekundenbereich). Das ganze läuft hier aber programmatisch: Neue temporäre Kopie erstellen und "sofort" importieren. Ich hoffe, das ist soweit verständlich ausgedrückt Workasround: In jeder Domäne eine Site, in der nur der PDC und der jeweilge Server stehen. Dann ist nicht nur AD zufrieden, sondern auch DFSR - das findet dann auch nur noch "the one" Das WLAN-Snapin war diesbezüglich auch speziell. Das hatte den Bug, daß es die DC-Auswahl in GPMC, die von GPMC an GPEdit (korrekt eigentlich: GPME.MSC) beim Aufruf weitergegeben wird, ignoriert hat und auch "irgendeinen" DC auswählte. Ergebnis: Klickte man in GPEdit auf "neue WLAN-Policy", wurde von GPEdit auf dem PDC im GPO-Container ein "Machine"-Container erstellt. Das Snapin selbst erstellt darin dann ein WLAN-Objekt, bei Bedarf aber auch den zugehörigen Container. Ging das nicht gegen den PDC -> Replikationskonflikt (CNF:) für den "Machine"-Container, wenn es den nicht vorher "aus Gründen" schon gab -> GPO kaputt.

Danke für die schnelle Rückmeldung - so in der Art denke ich das auch - aber in der Beschreibung fängt die Lösung damit an: "1. Start Management Shell on the Mailbox server. ..." ähm - genau damit kommt ja zuvor genannter Fehler. Wie komm ich an den Exchange sonst lokal dran? ist das für Systeme auf verschiedenen Servern geschrieben? hier liegt alles auf Einem. ah sorry, da war ich zu schnell, das Zert besteht ja - muss noch testen

Hi, ich vermute, du musst das neue Zertifikat im IIS einmal ans Exchange Back End binden: OWA, ECP, or EMS can't connect after removing a self-signed certificate from Exchange Back End website - Exchange | Microsoft Learn Gruß Jan

Moin, mir fehlen Ideen in welche Richtung ich suchen muss. Bislang finde ich nur Lösungsansätze, wo man die ManagementShell nutzt. Umgebung: Server 2012R2, Exchange 2013 - (läuft nur im Intranet mit einer handvoll Clients, ein lokaler Connector speist ihn mit Mails). Vor ca 2 Wochen habe ich ein abgelaufenes Zertifkat manuell erneuert - ohne Zertifizierungsstelle, da der Server nur intern läuft - lief danach einwandfrei (Clients mussten das Cert einmal speichern). Vorgestern hab ich ihn dann das erste Mal seitdem neu gestartet - danach war Exchange nicht mehr erreichbar. neben den Clients, die sich natürlich nicht mehr verbinden können gibt es lokal schon folgende Phänomene: - Exchange Administrative Center gibt nach Login einen 503 - Toolbox gibt nach Start einen Snapin-Fehler - Exchange Management Shell gibt nach Verbindungsversuch einen leeren Fehler Einen ersten Fehler konnte ich lösen indem ich im IIS-Manager im Verwaltungsdienst ein aktuelles Zertifikat zugerodnet habe. Damit ließ sich der Webverwaltungsdienst wieder starten. Fehlermeldungen gibt es natürlich viele, ich denke die beruhen natürlich auf einem Grundproblem - ich hatte den Ansatz folgende damit ursächlich zu verknüpfen - gefundene Lösungen setzen allerdings die Shell vorraus: "Ereignis 36874, Schannel Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung." oder diese: "Ereignis 2005 MSExchange Certificate Deployment Verbund- oder Authentifizierungszertifikat nicht gefunden: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. Das Zertifikat wurde am lokalen sowie an benachbarten Standorten nicht gefunden. Bestätigen Sie, dass das Zertifikat in Ihrer Topologie vorhanden ist, und setzen Sie das Zertifikat bei Bedarf bei der Verbundvertrauensstellung mithilfe von 'Set-FederationTrust' oder 'Set-AuthConfig' auf ein gültiges Zertifikat zurück. Die Übermittlung des Zertifikats an den lokalen oder die benachbarten Standorte benötigt möglicherweise etwas Zeit." Im IIS sehe ich 3 aktuelle Zertifikate, die am entsprechenden Tag erstellt worden sind - allerdings hat keines den Hashwert, der oben drin stand. Zudem heißt es dort: "Dieses Zertifizierungsstellen-Stammzertifikat ist nicht vertrauenswürdig. Installieren Sie das Zertifikat in dem Speicher vertrauenswürdiger Stammzertifizierungsstellen, um die Vertrauensstellung zu aktivieren." Hat er irgendwo noch das alte abgelaufende Cert drin gehabt und mit Neustart reingeschrieben? Oder fehlt ihm irgendwo, wie das neue heißt? Oder wo kann ich neue Zertifkate erstellen und neu einbinden? (ohne Management Shell etc) Danke für Hilfestellungen! lg Lutz

Wir hatten für die insgesamt 5 Admin einen separaten 5er Pack gekauft und auf dem Admin-RDS war auch der dazu gehörige Lizenz-Server Für die User auf den beiden Farmen waren die Lizenzen auf dem Dienstserver Der Auditor war sehr zufrieden damit…

Einmal das. Ebenfalls müsste er das ja auch erstmal verstehen und hinterfragen. ;) Ein anderer Gedankengang: Die beiden RDS CALs sind knapp 300 € (bzw. OEM wird man wohl die 5er oder 10er Packs kaufen), ob man sich dafür Gedanken machen sollte, ob sich ein Auditor Gedanken machen könnte. ;) EDIT: Nehmen wir an ich lizenziere das Windows OS per Datacenter und benötige 50 Admin User -> Dann sind das ja nur 25 "Admin TS" mit je zwei Usern, die ohne CAL zugreifen dürfen. Das sich die Nutzungsbedingungen in den verschiedenen Kanälen (OEM, Open, MCA, ...) unterscheiden (Re-Imaging, License-Mobility, ...), ist ja bekannt. An der Stelle hätte ich aber nicht mit Unterschieden gerechnet. Aber hey: Es ist Microsoft

Moin, Ich gehe davon aus, dass das nicht der Punkt ist, auf den ein Auditor sehr viel Zeit verwenden würde. Da gibt es für ihn anderswo mehr zu holen. Interessanter Punkt aber auf jeden Fall. Und guter Hinweis, dass die Angaben dort auch nicht eindeutig sind. Gruß, Nils

In meinen Augen ist das weiterhin ein Remote Desktop Szenario nur eben mit Admin Usern auf einem Server, von dem diese Ihren daily business machen. In den OEM Terms findet sich (microsoft.com/en-us/UseTerms/OEM/WindowsServer2022/2022Essentials/UseTerms_OEM_WindowsServer2022_2022Essentials_English.htm): In den Product Terms allerdings (Microsoft Product Terms): Laut den OEM Terms, würde ich bei meiner Sicht der Dinge bleiben. Bei den Product Terms schwanke ich jetzt und würde eher Richtung @lizenzdocs Sicht tendieren.

Hi all, in den PURS steht ja, dass 2 Admin-Zugriffe gleichzeitig durch die Server-Lizenz abgedeckt sind, auch für das Thema RDL. Wenn mehr als 2 gleichzeitig zugreifen müssen, dann für diese jeweisl 1 WIN- und 1 RDL-CAL( wenn diese zusätzlichen Admins auch auf den TS-Dienst zugreifen müssen) lizenzieren. So verstehe ich die PURs. VG, Franz

In den "Debatten" wird dann immer recht schnell Grommunio, MDaemon oder auch mailcow genannt. Ich hatte noch keine Muße, mir eine der Lösungen anzusehen. Überzeugt bin ich allerdings ungetestet von mailcow (Funfact: Als Grund zum Wechsel den Subscription Zwang nennen und dann zu Grommunio oder MDaemon wollen. ;-))

Weil die bösen Angriffe ja alle nur von außen kommen. ;) Aber am Ende eh egal, so wie viele schon jetzt ihre Exchange Server nicht gepatcht haben, wird das auch niemanden stören.

naja ... ist dann wirklich die Frage, ob man dann den Exchange 2019 nicht einfriert und nicht mehr nach außen veröffentlicht. Intern weiter verwenden, Mail nimmt ein Gateway an und versendet auch nach außen ... Mobiltelefonanbindung wird überbewertet ... dann gibt's halt Mail nur noch per VPN aufs Handy Oder man drück Exchange in die Tonne und wechselt auf ein anderes Produkt ... MDaemon vielleicht - kann mit Outlook spielen, Mobilgeräte anbinden, ...? Irgendwie hab ich so den Eindruck, dass in vielen Firmen zur Zeit bisserl über Softwarewechsel nachgedacht wird ... VMWare -> Hyper-V, Proxmox, XCP-ng, ... Exchange -> noch keine Ahnung ...

Moin, Hmm, so habe ich das noch nie gehört. Klingt fast wie eine Frage für den @lizenzdoc. Gruß, Nils

Hi, die User administrieren an der Stelle aber nicht den "Admin Terminalserver", den Sie zum administrieren der anderen Servern benutzen. ;) Also ist hier - meiner Meinung nach - ab User 1 eine RDS CAL notwendig, egal ob RDS Rolle installiert oder nicht. Die "kostenlosen" Zugriffe per RDP sind nur für administrative Zwecke auf dem Server erlaubt, auf den zugegriffen wird. RDP Verbindung auf Server1, um Windows Updates oder eine Anwendung auf Server1 zu installieren: "Kostenlos" RDP Verbindung auf Server1, um per RSAT andere Server (Server2, 3, 5) zu verwalten: RDS CAL pflichtig Gruß Jan

Ein Einsprungserver nur für die Admin hat noch den Vorteil, das man seine Tools nur auf einer Maschine installieren muss und dann allen anderen Admin zur Verfügung steht Auch Wartung von Remote etc. macht das viel einfacher, sogar im Haus wenn man z.B. bei einer Kollegin oder Kollegem am Platz sitzt und mal eben was erledigen will Da ich davon ausgehe, das ihr eigenen privilegierte Konten verwendet würde ich den RDS Host und 3 Lizenzen für euch drei installieren Ansonsten schönen „Vatertag“ und das mir keine Klagen kommen…

Alles klar, vielen Dank für die schnelle Info :)