Squire

Guten Morgen zusammen, Kaffee ist frisch...

@daabm ... da war ich eigentlich schon ne Stunde am Schaffen 6 Uhr Start im Homeoffice hat den Vorteil, dass um 13:30 Feierabend ist (für den Hauptjob) und dann kann ich in Ruhe für meine eigene Firma arbeiten ... und dafür mach ich heut die Kaffeeküche zu

Die Kaffeeküche ist seit einer Stunde offen ... bedient euch ... Viel Spaß und wenig Stress in dieser Woche

Ich hab hier F-Secure für Exchange laufen auf unseren Büchsen laufen (2016 bis 2019 im Einsatz) davor als Gateway NoSpamProxy Verrichtet klaglos seinen Dienst

Leider funktioniert die SMB1 Proxy Geschichte nicht mit Windows CE Clients ... Zumindest nicht mit den Steuerungen/Werkzeugmaschinen, die wir haben. Der Proxy selbst funktioniert. Das haben wir mit Windows XP Clients getestet. Die Windows CE Steuerungen gehen nicht ums Verrecken. Entweder brauchen die zwingend einen WINS (haben wir nicht mehr) ... einfach b***d ... vom Hersteller der Maschinen ist da auch keine Hilfe zu bekommen (außer kauft neu ... aber sechs, bzw. siebenstellige Beträge werden nun mal nicht so schnell und gern ausgegeben ...

Moin Board, Kaffee ist in der Küche ... frostig draußen ... -6°C, klarer Himmel

und mittlerweile kann die AVM 7490 WireGuard ... [wie die Zeit vergeht ... sorry could not resist] Bevor Du einen PC hinstellst ... hol dir für wenig Geld eine gebrauchte Sophos SG oder XG. Da kannst dann auch pfSense drauf laufen lassen.

Nein, das sind die eigenen Keys des Kunden! Keine fremden - sowas macht der Kunde und ich auch nicht! @NorbertFe doch Frage stellt sich, da ich ja dann mit einem einzigen MAK Key diverse andere Server aktivieren muss.

Mal sehen ... ist vielleicht eine Idee ... der Kunde hat noch einen weiteren Standort mit einem einzelnen 2012R2 Hyper-V ... der muss ja auch noch ersetzt werden. Das werde ich mal ansprechen .... Aber ist das dann lizenzrechtlich sauber, wenn ich für die Standard Server auf dem ESX Cluster dann einen KMS Key verwende?

nein das ist sein eigener Key (er hat eine zusätzliche ROK Standard Lizenz für den physikalischen Backup Server) Und was Datacenter angeht, dann müsste ich ja lauter Datacenter installieren oder bei einem inplace Update ein Versions Upgrade machen

Hallo zusammen, ich hab für einen Kunden für seinen ESX Cluster Windows 2022 Enterprise ROK Lizenzen. Die Enterprise Lizenzen beinhalten ja ein Versions Downgrade Recht (Enterprise -> Standard) Der Enterpise Key wird natürlich nicht für die Standard-Edition angenommen (ungültiger Lizenzkey). Dell schreibt - einfach einen Lizenzschlüssel der Standard Edition verwenden. Selbigen hab ich von einer weiteren Lizenz für den Kunden. Aber irgendwie ist das ganze "unschön" finde ich. Einen KMS Key hat der Kunde nicht ... also einfach alle Server im Cluster mit dem gleichem Standard Key aktivieren? Wie wird das sauber und schön?

Nebenbei... Berechtigungen auf User Basis macht man nicht. Immer Gruppen! Dann guckst den User an und anhand der Gruppen weiß man auch wo er zugreifen kann. AGDLP Prinzip!

Seit dem Wochenende sind beide 2019er aufgesetzt, DAG eingerichtet und keine Zertifikatsmeckereien am Montag ... Mein oben beschriebener Weg war genau richtig. Hat ja der Kollege @cj_berlin auch bestätigt. Jetzt müssen noch ein paar Anpassungen für die "Um-Systeme" [Mailarchivierung, MDM, Disclaimerlösung] vorgenommen werden ... dann geht das Mailboxschubsen an.

Clickshare ist ein Präsentationssystem (haben wir auch im Einsatz) ... Du steckst einen USB Dongle am Rechner an, startest die Exe und kannst auf Knopfdruck auf dem Dongle Deine Powerpoint bzw. Deinen Desktop über nen Beamer schnurlos an die Wand schmeißen. Eigentlich ne sehr nette Lösung (bis auf ... die USB Dongles scheinen in den Besprechungszimmern einem natürlichen Schwund zu unterliegen ... verschwindet immer mal wieder ein Dongle ...

die SCPs zeigen alle auf die virtuellen Services am Kemp. Ja ist schon lustig ... mal ist man nicht schnell genug, mal muss man "ewig" warten, bis die Replikation durch ist ... was mich aber trotzdem interessiert ist, wie der Client den 2019er findet, wenn doch die SCPs auf den Kemp zeigen und der den auch noch nicht kennt...

@cj_berlin Guten Morgen Evgenij, ich hab die Verzeichnisse mit Frankys Script ausgelesen und gesetzt (Dieses hier) man muss ja das Rad nicht zweimal erfinden. Auf Dauer lass ich den Exchange eh nicht aus. Ich denk fast, dass ich die Geschichte erst am Wochenende weiter verfolge. Dann rufen nicht gleich irgendwelche User an und motzen ... Aber schön, dass Du meinen Weg bestätigst, hatte schon an mir zu zweifeln begonnen Noch eine Frage zu dem Hybrid Gedöns, das ist in der Tat für mich relativ neu ... muss ich da den Hybrid Wizard nochmal laufen lassen, oder genügt es die beiden neuen Exchange in den Connectoren hinzuzufügen?

hab mir einen genommen und grübel gerade ... Moin zusammen

Hallo, ich hatte gestern ein Phänomen, das ich mir nicht so ganz erklären kann ... Umgebung: AD, mehrere Domänen, eine Exchange Organisation (mehrere 2016er Server). Bei uns eine DAG (2 Server) hinter einem Kemp Päarchen. Hybrid Szenario für O365 (Mailboxen alle on Prem) Ziel: Dazu sollen jetzt zwei 2019er Exchange als DAG kommen. Die Mailboxen aus der 2016er DAG sollen auf die 2019er verschoben und die 16er dann zurückgebaut werden. Stand jetzt Ein 2019er wurde installiert, die virtuellen Verzeichnisse identisch zu den 2016ern gesetzt. SplitDNS ist im Einsatz. Das öffentliche Zertifikat, welches wir auf den 2016ern verwenden hab ich auch im 2019er drin. Der 2019er ist bisher noch in keinem Connector hinterlegt, ebenso wurde der 2019er nicht am Kemp bekannt gemacht. Die SCPs zeigen alle auf die virtuelle Adresse/Namen des Kemp Jetzt das, was ich nicht verstehe ... Outlook bringt eine Zertifikatswarnung, dass auf dem korrekten öffentlichen Zertifikat der interne Name nicht drauf ist. Sprich der Server meldet sich bei Outlook mit seinem internen Namen und mit dem korrekten externen Zertifikat. Wie kann das eigentlich sein? Outlook quatscht doch normal über den virtuellen Service auf den Kemp Loadbalancern zu den Exchangeservern. Wieso die Meldung des 2019ern? Mein Plan war die beiden 2019er fertig zu installieren, virtuelle Verzeichnisse zu setzen, Zertifikat einspielen, DAG erstellen, dann am Kemp bekannt machen (sollte hierzu ein neuer Service angelegt werden oder kann ich die bei den 2016ern mit hinzufügen?), Connectoren anpassen (Sendeconnectoren) ... Im Moment hab ich den 2019er wieder heruntergefahren, um die User durch die Zertifikatsfehler nicht zu irritieren. Frage: Passt mein Upgrade Weg? Warum kommt der Zertifikatsfehler?

oh ... hab ich nicht realisiert. Wie auch immer ist ja noch aktuell

na ... da kommt ja doch noch was on prem: https://practical365.com/future-for-exchange-server-june-2022/

Moin, frischer Kaffee steht in der Küche! Schöne Woche allen!

Macht der Gewohnheit ... ich mach das immer in der Root Domäne mit dem Schemamaster ... aber ... wie auch immer again what learned

Genau das ist der Weg! Die meisten sind zu ungeduldig und versuchen zu installieren bevor die Replikation durch ist. (das /prepareschema muss in der Domäne stattfinden, in der der Schema Master ist - es muss aber nicht auf einem DC ausgeführt werden) Nebenbei bemerkt - nicht jedes CU erfordert ein Schema Update - wenn, dann ist das in den Notes oder auf dem Exchange Blog angegeben

Hi, wenn Du ein Gerät zum Löschen markiert hast, musst Du den Hauptdialog auch mit Speichern beenden. Erst dann wird das Gerät gelöscht!

ja - ist schon erstaunlich, dass man mit gleicher Hardware, aber unterschiedlicher Konfiguration eine solche Verbesserung erreichen kann. Danke für die Rückmeldung!