Squire

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!

Wie Norbert oben geschrieben hat: Hauptmailbox im CacheMode und für die zusätzlichen Mailboxen ausschalten und diese im OnlineMode verwenden. Die fehlerhafte Aktualisierung kann auch von einer verhunzten OST Datei herrühren - also unter %localappdata%\microsoft\outlook die OST wegwerfen (nachdem geprüft wurde, dass alle Emails, die verschoben/gesendet wurden, wirklich am Server angekommen sind). Die OST wird von Outlook beim Starten denn neu erstellt ...

ja - Ein 2008R2 ist nicht neuester Stand - der ist schon ne Weile EOL. Bring das System auf einen aktuellen Stand! Der 2008R2 ist schon tot und Exchange 2013 stirbt im April 2023! Mehr als genug Grund einen neuen, aktuellen Server hochzuziehen und die Mailboxen zu migrieren. Nebenbei: ohne grundlegende Infos zu Deinem System kann man absolut nix sagen!

Zum Beispiel die Sicherungen mit Veeam Agents (Windows/Linux/Applications) - die werden vom Backup Server angetriggert und schreiben dann alleine in ein Repository. Ich hab z.B. an einem Remote Standort einen Hyper-V mit einem Repository auf einer QNAP ... der Hyper-V Agent schreibt dort direkt in den Share. (Sieht man schon anhand der Schreibrate, da geht nix über den VPN Tunnel zum Backup Server - nur die Session Statistics und Sesson Metadaten) Oder eben Spectrum Protect oder Networker ... die Agents bei letzerem schreiben da über DBBoost z.B. direkt in die Datadomain rein. Die klassischen Snapshot Sicherungen (auch bei Storage Snapshots) bei Veeam sind da anders - da zieht der Backup Server die Daten vom Snapshot

naja, eigentlich jede Agent basierte Software. Der Backup Server triggert zwar den Agent, aber der schiebt dann. Networker hat das, neben TSM/SpectrumProtect auch so gemacht.

Ich hab meine Miezekatze auf meinem Arm liegen ... signalisiert mir damit: Genug am PC getippt ... Wünsche euch allen frohe und ruhige Feiertage (ohne irgendwelche Notfalleinsätze)!

3-2-1 Regel - Siehe: https://www.veeam.com/blog/321-backup-rule.html ich zieh die Daten per Veeam in ein Repository (Backup Server ist nicht in der Domäne), dann gibt es eine weitere Kopie in einer Quantum Dedup Appliance (kann nicht über NFS oder SMB angesprochen werden, sondern über ein eigenes Protokoll. Ähnlich DellEMC Datadomain -> DBBoost oder HPE StoreOnce -> Catalyst) und dann wird noch auf LTO rausgeschrieben. von der Quantum gibt es eine Community Version mit 5 TB RAW Kapazität. Dedup Raten bis zu 20:1 ... aktuell lieg ich hier bei 7,4:1 - je mehr Sicherungen da reinlaufen, desto höher das Dedup Verhältnis. Ich hab jetzt 28 Restore Points da drinnen mit GFS Settings aktiv. Für eine kleine Firma durchaus ausreichend ...

gibt es auch bei mir unter Windows 10 22H2 ... und ich hab das definitiv nicht selbst da hin kopiert. Entweder kam das mit den PowerCLI von VMware oder NuGet ... curl --help Usage: curl [options...] <url> -d, --data <data> HTTP POST data -f, --fail Fail fast with no output on HTTP errors -h, --help <category> Get help for commands -i, --include Include protocol response headers in the output -o, --output <file> Write to file instead of stdout -O, --remote-name Write output to a file named as the remote file -s, --silent Silent mode -T, --upload-file <file> Transfer local FILE to destination -u, --user <user:password> Server user and password -A, --user-agent <name> Send User-Agent <name> to server -v, --verbose Make the operation more talkative -V, --version Show version number and quit This is not the full help, this menu is stripped into categories. Use "--help category" to get an overview of all categories. For all options use the manual or "--help all".

warum Restore? Falscher Weg! Updateproblem hin oder her ... der alte DC läuft doch noch! Nimm den neuen DC wie Nobby geschrieben hat in die Domäne auf. Mach ihn zum DC und lass replizieren! Einfach dem Fahrplan von Nobby folgen!

Was ist der Grund für reverse incemental? NAS als Backupziel ist suboptimal. Ich würde das eher als Block LUN per iSCSI an den Backupserver als Laufwerk durchreichen, dann ReFS verwenden