Squire

das hatte ich schon versucht - Datei wird zum Download angeboten und kann geladen werden Sprich das klappt alles. (Die W10 und W2022 registrieren sich ja und laden auch) ... die 2012 registrieren sich ja nicht mal am WSUS (kein einziger sichtbar) (Verteilen oben abgeändert )

Hi, ich stolper grad über ein Phänomen ... Neu aufgesetzter Win 2022 WSUS Server ... holt Updates und stellt diese wie er soll an alle Win 10 und Win 2022 Clients zur Verfügung... nur die paar alten Windows 2012R2 Server registrieren sich nicht mal am WSUS. Die Policies wurden bis auf Änderung des WSUS Server Namens nicht verändert (vorher gab es einen 2012R2 als WSUS). Der neue WSUS ist wie der alte für SSL konfiguriert. Bei den 2012ern kommt als Fehler bei der Update Suche 80072EE6. Kein einziger der 2012R2 mag den neuen ... Auszug aus dem Windowsupdate.log 2023-03-20 18:09:07:218 852 6e4 Agent WARNING: WU client failed Searching for update with error 0x80072ee6 2023-03-20 18:09:07:218 852 6e4 IdleTmr WU operation (CSearchCall::Init ID 9, operation # 780) stopped; does use network; is not at background priority 2023-03-20 18:09:07:218 852 6e4 IdleTmr Decremented idle timer priority operation counter to 1 2023-03-20 18:09:07:218 852 1bd8 AU >>## RESUMED ## AU: Search for updates [CallId = {E4467EBC-8A12-4674-96F9-E92F4B00C1FD} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2023-03-20 18:09:07:218 852 1bd8 AU # WARNING: Search callback failed, result = 0x80072EE6 2023-03-20 18:09:07:218 852 1bd8 AU ######### 2023-03-20 18:09:07:218 852 1bd8 AU ## END ## AU: Search for updates [CallId = {E4467EBC-8A12-4674-96F9-E92F4B00C1FD} ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}] 2023-03-20 18:09:07:218 852 1bd8 AU ############# 2023-03-20 18:09:07:218 852 1bd8 AU All AU searches complete. 2023-03-20 18:09:07:218 852 1bd8 AU # WARNING: Failed to find updates with error code 80072ee6 2023-03-20 18:09:07:218 852 1bd8 AU AU setting next detection timeout to 2023-03-20 22:09:07 2023-03-20 18:09:07:218 852 1bd8 AU Adding timer: 2023-03-20 18:09:07:218 852 1bd8 AU Timer: 31DA7559-FE27-4810-8FF6-987195B1FD98, Expires 2023-03-20 22:09:07, not idle-only, not network-only 2023-03-20 18:09:07:218 852 1bd8 AU Currently AUX is enabled - so not show any WU Upgrade notifications. 2023-03-20 18:09:07:218 852 1bd8 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037 2023-03-20 18:09:07:218 852 1bd8 AU WARNING: Failed to get Network Cost info from NLM, assuming network is NOT metered, error = 0x80240037

Moin - Freitag is, schöner Sonnenaufgang war (total kitschige Farben, helles türkisblau, rosa, orange, rot,...) Kaffee ist frisch .... und übermorgen dann Wartungsupdaterunde auf all unseren Servern (so kann man dann auch den Sonntag verbringen)

ne ich hatte heute früh nur Wasser getrunken und keinen Kaffee

Natürlich hat Gangl sowas https://www.gangl.de/product/notification-agent.html

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/