LukiHoer

Von üben kann hier nicht gesprochen werden. Der Kunde konnte sehr gut auf eine temporäre extern Synchronisation verzichten. Seine Outlook Kontakte hatten sich intern schon mit dem iPhone synchronisiert! ;) Das wundert mich leider nicht. Genau das ist das schlimme. Wir haben über "Nacht" alle Server gepatcht.. einen zu spät. Und das war ein Handwerker mit 3 Mitarbeitern/Postfächern, Pech bzw. nicht schnell genug. Nicht fahrlässig oder mutwillig. Einfach nur Pech. Aber verhindern können wir Systemintegratoren das in solchen Fällen auch nicht.

Ich hoffe das es SPÄTESTENS nach den Hackerwellen keinen mehr gibt der den HTTPS Port an den Exchange weitergibt! Die SP macht ihren Job bei uns schon seit Jahren (Wortmann Partner....) Nie große Probleme gehabt. Bei den Filtern sind wir mittlerweile bei vielen hingegangen und lassen betroffene Inhalte löschen und Markiert zustellen. Den Rest erledig dann das lokale Antivirenprogramm von anderen Herstellern... sind davon Fan das verschiedene von Engines laufen. Hatten schon das Problem mit der Festplatte ;) Auch wenn ich nach wie vor die Handhabung und vor allem die Begrifflichkeiten nicht top finde bei SP. Kabelmodem mit DHCP.... ne ist klar. Aber zurück zum Thema! Wieder Einmal schnell und unkompliziert Hilfe erhalten. Vielen Dank euch beiden! Vielleicht sollten wir mal davon weg gehen alle Kunden alle 5 Jahre auf den "neusten" Stand zu bringen. ;) Dann fällt sowas schneller auf und man hat keinen Druck sich diese Infos innerhalb kürzester Zeit zu organisieren. Gruß!

Zu Punkt 1 - Jaaa eine Info zu wenig ;) CU13 installiert, hatte die Hoffnung das auch das SU schon drinne ist um sicher zu gehen habe ich das Script ausgeführt. Zu Punkt 2- Das ist die Antwort die erhofft hatte! :) :) Zu Punkt 3 - Ja auch diese Info habe ich nicht geschrieben. Seit dem wir Exchange ohne VPN von Unterwegs verfügbar machen tunen wir das über ein Revers-Proxy. (Securepoint, falls das deine Frage war) Achja... aber kann man dann nicht zu mindestens davon ausgehen das alle SU's bis zum neuen CU mit drin sind. Es wurden mir definitiv die Lücken aus ganz 2022 angezeigt vor SU Juni 2023.

Um dem Systemintegrator nicht in den Wahnsinn zu treiben. ;) Jup, sorry hätte ich direkt schreiben sollen. Auch frisch heruntergeladen: V23.07.13.1135

N'Abend! Ich habe heute seit langen einen Exchange Server neu aufgesetzt. Der Neukunde freut sich sehr über die Funktionen ;) Installation kann ich mittlerweile im schlaf. NUR nach dem ich alles fertig gestellt habe und als letzten Step den EX aus dem Internet erreichbar machen wollte, habe ich nochmal den HealthChecker laufen lassen... als ob MS das Juni Update schon in die ISO packen würde.... pfff.... Aber ich lasse mich ja gerne positiv überraschen! Überrascht war ich auf jeden Fall nachdem das Script mit jede Sicherheitslücke seit Januar 2022 aufgelistet hat!! Mit Tränen in den Augen habe ich dann mit dem Juni 2023 Update angefangen... Tag war lang, wieso ich von hinten angefangen hab weiß ich selber nicht. Seit dem zeigt aber das Script keine einzige Sicherheitslücken mehr an?! Soweit ich mich erinnere waren zumindest die Oktober und November Updates deutlich größer als das Juni 2023. Ich kann mir also nicht vorstellen das diese mit dort mit drin sind. Es stand doch bestimmt schon jemand von euch vor der selben Frage. Lügt mich das Script nach dem Juni 2023 Update an und ich muss die anderen auch noch installieren? Oder sind wirklich alle Sicherheitspatches im Update enthalten? Noch zur Info: Server 2022 Std., EX2019 Std. neu von MS heruntergeladen. ps. er ist natürlich noch nicht aus dem WWW erreichbar... Wünsche vorab schonmal einen schönen (Feier)Abend! Gruß Luki

Das haben wir bisher schon so gemacht. Es geht dabei nur um eine Arbeitserleichterung für uns hinsichtig der Benutzer. Die immer wieder eingerichtet werden müssen. Blaupausen für die eigenständigen Domänen und Serveranlegen gibt es schon. Und ich weiß jetzt das mein Ansatz sowieso vollkommen falsch war weil eine nachträgliche Trennung nicht möglich gewesen wäre. Der Kunde weiß von unserer Idee nichts... wir hätte es Ihm erst präsentiert wenn es eine sichere und saubere Lösung mit Ersparnissen hin sichtig der Einrichtung gewesen wäre. Ich habe nicht gesagt das alle Böse sind... damit hätte ich mich ja mit einbezogen. Wobei ja oft nicht der Dienst leistende sondern der Nutznießer der Böse wäre/ist. Vielen Dank euch allen!

Das ist ne Aussage mit der ich arbeiten kann! Vielen Dank! Dann konfrontiere ich meine Chef mal damit. Hätte nicht gedacht das die M´möglichen Microsoftlösungen Komplizierter/Zeitaufwändiger ist als das manuelle anlegen von Benutzern ist. Wie gesagt Vielen Dank! ps. Ist denn der DC-Test2 jetzt der letzte Domaincontroller in der Domain Test2.de oder verabschiedet sich Test1 dann auch? ;)

Testunternehmen 2 läuft unter dem Namen der Hotelkette nicht unter dem Namen von Testunternehmen 1... daher die Unterschiedlichen Domänen. Die Mitarbeiter von Testunternehmen 1 arbeiten aber bei Testunternehmen 2. Das wiederhotl sich bei jedem Hotel was Testunternehmen 1 kauft. Und ich/wir wollen uns das Anlegen der Benutzer (in dem Fall 70) bei jedem neuen ersparen. Also um noch etwas konkreter zu werden. Die Server gehören TU2 aber gearbeitet (auf dem Terminal) wird von TU1.... zu mindestens bis zum Verkauf.

Das wäre eine schöne Welt in der sich die Dl untereinander so helfen wie du mir vorschlägst. Leider haben wir schon den Fall gehabt das vorneherum die Projekt wie geplant mit Hilfe durchgeführt wurde und hintenherum die Kunde gesagt bekommen hat das es eine bessere Lösung gibt um 2 Mal zu kassieren. Aber dafür gibt es ja diese Foren in denen sich die Dl oder internen sich gegenseitig helfen ohne einen wirtschaftlichen Hintergrund. Damit es etwas durchsichtiger wird. Test1 Unternehmen kauf ein Gebäude und macht ein Hotel daraus welches durch einer der großen Hotelketten vermarktet wird. Also Testunternehmen baut das Hotel auf, sucht sich ein Partner (Hilton oder so), kümmert sich um Angestellt, Arbeite aber auch selber als Angestellt im Hotel, betriebt das Hotel einige Zeit und verkauft es dann nach einiger Zeit mit Gewinn. Ähnelt also einer umgedrehten Franchise Kette... Ein bessere Beispiel finde ich nicht xD Ich Probe ja nicht am leben Objekt habe ja ein Testsystem. Danke für den Link ich schaue mal weiter ob ich ein Einrichtungsbespiel finde und teste es dann mal! Ich würde es gerne lernen ohne das mir meine Kollegen den Hals umdrehen! ;) für Tipps bin ich dankbar! Natürlich bin ich auch für dein Wissen dankbar @NorbertFe!!

Das stimmt. Der Chef würde dabei auch auf den Verdienst verzichten. Es gibt aber 2 Gründe das nicht zu tun. 1. Was man sich selbst beibringt vergisst man nie, außerdem lernt man dann Sache wie ich beispielweise heute, weil der DL das mit den Tree-Domains durchgezogen hätte. 2. Kommt dann immer die Frage beim Kunden auf: Wieso sollte ich dann nicht zu dem 2ten Dienstleister wechseln wenn er besser auf meine jetzige Situation passt.... Die Überlegen das der 1 Dl. alles andere vielleicht besser kann bzw. schon kennt kommt leider heute nicht mehr auf. Heute zählt gefühlt nur: Wer kann mir jetzt sofort am günstigsten helfen. Weil die Gefahr besteht das sich das Unternehmen Test1 von dem Unternehmen Test2 trennt bzw. es verkauft fällt leider Ansatz 1 aus weil ein nachträgliches trennen viel Arbeit mit sich bringt für den Test1 uns nicht bezahlen wird und fraglich ist ob der Käufer das bezahlen möchte. Hast du ein seriösen Link oder ein Tipp für mich im Bezug auf Trust Einrichtung. Wie schon erwähnt: Wenn man sich selbst etwas beibringt vergisst man es nie wieder! ;) Und vielleicht nochmal: Kann ich Test2 zurückstufen ohne Test1 zu schreddern um meine Kollegen Test1 nur kurz weg zu nehmen. Schonmal vielen Dank vorab für euer Wissen und Tipps!! @NilsK und @testperson Gruß LukiHoer

Okok... Tree böse. Welchen Lösungsweg würdest du empfehlen? 70 Benutzer aus Test1 auf Test2 anlegen scheint mir etwas umständlich. Es muss doch einen weg geben das Test 1 auch auf Test2 mit den vorhandenen Benutzer arbeiten kann. Und dann noch eine Frager dazu: Wenn ich den vorhandenen Test2 wieder zurückstufe ist der dc-test2 der letzte innerhalb der Domäne oder darf die Domäne nicht gelöscht werden wenn ich die Test1 behalten will? Sicherung wiederherstellen ist zwar möglich aber dann nehme ich meinen Kollegen erstmal das Test1 weg.... Die werden sich nicht freuen! ;)

Hallo NilsK, Sowohl die Benutzer aus Test1 also auch die aus Test2 sollen auf der Test2 arbeiten. Test2 Benutzer aber nicht auf Test1. Und es sind unterschiedliche Domains. Test2 ist ein Tochterunternehmen welches selbst geführt ist aber Test1 gehört. DAS kann sich aber auch schnell ändern, sodass die Test1 Benutzer nach verkauf kein Zugriff mehr auf Test2 haben dürfen. Nach meiner Recherche ist/war die Tree/Methode da die "sauberste". Ist dem nicht so? Problem Kurz und knapp: Der Exchange in Test2.de lässt sich nicht installieren.

Hallo Zusammen, vorab: TESTNETZWERK als Vorbereitung auf ein Produktivnetzwerk. Ich habe zum ersten Mal den Auftrag eine Tree-Domain zu installieren für ein Franchise Unternehmen. Vorrausetzungen: Vorhandene Domäne SERVER2016 : test1.de, DC: dc.test1.de 192.168.100.2 (,wahrscheinlich unwichtig es gibt einen Exchange *.100.3 für Domain test1.de) Site-to-Site VPN zur Tree-Domain... Portfirewall Any to Any accept... also keine Blockenden innerhalb der Netze über VPN. Routing logischerweise eingerichtet, Kein Proxy vorhanden. Ziel des Ganzen SERVER2022: Domäne: test2.de, DC: dc-test2.test2.de 192.168.101.2 , Exchange mit 101.3 für Domain test2.de (später im Produktivnetz dann auch noch DB, Terminal, ect) Wie ich vorgegangen bin: 1. 2ten DC(-test2) im 101er installiert 2. Verbindung von DC zu DC-Test2 und andersherum per pings getestet 3. Dem DC-Test2 den DNS Server DC (100.2) gegeben 4. AD per Servermanger installiert 5. DC-Test2 hochgestuft... add to existing forest.. tree Domain Test1.de und test2.de eingeben. Anmelden mit Test1\Administrator............. 6. 1. Blick nach dem Neustart alles i.o. Domain erstellt. AD-Tools sind alle da. AD-Vertrauensstellung sieht gut aus. 7. Spaßeshalber dem Administrator aus Test1 RDP-Rechte auf DC-Test2 gegeben. Anmeldung i.o. 8. Wieder als Test2\Administrator rein und, weil ichs mal bei Frankys gelernte hab, Exchange-Admin angelegt. 9. Hier mein erstes Problem. Der Exchange-Admin muss natürlich die benötigten Rechte haben. Also Domänen-Admins -> i.o, Organisations-Admin-> Fehler: Name nicht gefunden?! Schema-Admins das selbe. weder im Suchpfad Test2 noch Test1?! Exchange-Admin von Test1 geprüft. Gruppen sind da.... 10. Das Setup vom Exchange hat dann auch nicht funktioniert weder mit den beiden Exchange-Admins noch mit den beiden Administratoren. (war mir vorher schon klar aber die Hoffnung stirbt zuletzt) 10.1 Problem beim Überprüfen des Status von Active Directory: Es wurden keine Exchange-Objekte auf Organisationsebene erstellt. Diese Objekte können nicht während der Installation erstellt werden, weil sich der lokale Computer nicht in derselben Domäne und nicht im selben Standort wie der Schemamaster befindet 10.2 Active Directory ist nicht vorhanden, oder es kann keine Verbindung damit hergestellt werden. -> der Server selber ist aber in der Domäne Test2.de 11. Nochmal die Kommunikation zwischen den beiden DC's auf Netzwerkebene geprüft... ping, tracert etc. alles i.o. Routing funktioniert. 12. Ereignissanzeige auf dem DC-Test2: 1. Fehler: Der DFS-Replikationsdienst konnte keine Verbindung mit dem Domänencontroller "" zum Zugriff auf die Konfigurationsinformationen herstellen. ...... (wieso "" muss da nicht DC.test1.de stehen?) 2. Fehler: Der DNS-Dienst wurde mit weniger Rechten gestartet, da KDC zurzeit nicht verfügbar ist. 3. Fehler: Der DNS-Server konnte keine integrierte Verzeichnispartition "DomainDnsZones.test2.de"erstellen. Fehler: 9906. 4. Fehler: Der DNS-Server hat einen kritischen Active Directory-Fehler ermittelt. Stellen Sie sicher, dass Active Directory ordnungsgemäß funktioniert. Die erweiterten Fehlerdebuginformationen (die eventuell leer sind) lauten "00002199: SvcErr: DSID-03201641, problem 5002 (UNAVAILABLE), data 8585". Die Ereignisdaten enthalten den Fehlercode 13. ABER Im DNS Manger für Test2.de sieht alles i.o. aus. Namen werden aufgelöst. 14 Verzeichnispartition ist da... zumindest ist das die Meldung wenn ich eine neue erstellen will. 15. Im AD Verwaltungscenter bei beiden DC's jeweil die andere Domain hinzugefügt und Testbenutzer erstellt. Replezierung funktioniert in beide Richtungen. 16. Auf Grund des Fehlers 10.1 -> netdom query fsmo Schema-Master und Domänenname-Master = DC.test1.de -> Ist das schon der Fehler? Wenn ja was ist wenn ich diese auf den DC-test2 verschieben? läuft danach noch alles im Test1 Netzwerk? Würde das auch wenn es nur ein Testnetzwerk ist nur ungerne machen ohne sicher zu sein. Weil der Exchange im Test1.de als "Vorlage" für einiges dient. müsste also alles dokumentieren damit meine Kollegen sich an dieser Doku orientieren und nicht mehr an dem Exchange. Eigentlich soll ja das Ziel der Tree-Domain sein das AUCH unterschiedliche Exchangeversionen miteinander bzw. unabhänig laufen können weil diese ja garnicht miteinander kommunizieren sollen. Zumal ich ja sowieso keinen älteren Exchange installieren möchte sondern nur einen 2019er. Es fehlt mir ein wenig der Ansatz was das Ursprungsproblem ist. Ist schlichtweg beim Heraufstufen was schief gelaufen? Gibt es nur Grundkonfigurationen die für eine Tree-Domain benötigt werden? Für jeden Ansatz bin ich dankbar weil der Kunde natürlich die Installation schon gerne vorgestern gehabt hätte. Und bitte nicht die Aussage: "Einen Dienstleister anrufen" treffen. Ich bin der Dienstleister. Und wenn immer nur die DL die es schon wissen Projekte umsetzten wird es irgendwann keine mehr geben die es könnten. Gruß LukiHoer

Ich finde es einfacher für reine Lizenzkonten die Passwörter unterschiedlich zum Domänenkonto zu halten. Damit kann der Admin auch Datenschutz umgehen wenn es zur Neuinstallation kommt ;) Also: 1. Neues Profil = beim anlegen Fehlerbild identisch. 2. Webproxy ja aber für interne Kommunikation deaktiviert. Habe aber auch Testweise den GW der DC's, Exchange's, und meine Testclients in ein "anderen" Router im Netz gesetzt. (Keine sorge den Router bzw die 2te IP des Routers/Proxys habe ich natürlich direkt wieder physisch entfernt ;) ) 3. Split DNS ja. Auch wenn ich/wir oft damit arbeiten vermute ich da meinen oder den Fehler weil: Habe die Einträge zurück auf den "alten" Exchange gesetzt und siehe da die Outlooks starten auch intern wieder Problemlos. Dazu folgende Infos: Die Postfächer liegen schon auf dem neuen.... Test per OWA nach der Mig war ja auch io. Beide Exchange haben den neuen DC als als DNS-Server. Den alten DC habe ich mittlerweile sogar schon runtergestuft und entfernt. Ich habe die Einträge im DNS jetzt schon mehrfach hin und her getauscht um Tippfehler meinerseits auszuschließen. OOOODER Gibt es vielleicht noch ein unterschied in der Authentifizierung von einem 2016 zu 2019 den ich nur nie bemerkt habe? Den Kunden haben wir im Sommer übernommen weil schon der Vorgänger massive ausfälle und Datenverlust am Exchange bzw. Mailtechnisch verursacht hat. Nur wie schon erwähnt haben wir alle damaligen Problemchen beseitigt und seit dem läuft alles einwandfrei. Nicht das der irgendwas abweichend der "Norm" vorgenommen hat was bisher nicht zum tragen gekommen ist weil kein 2019er da war. Wir haben im Januar nochmals ein Wartungsfenster daher werde ich es erstmal so belassen um keinen Druck zu bekommen. Es ist zwar nicht schön aber auch nicht pauschal unsauber. Endgültig würde ich das natürlich schon gerne Umstellen. Für weitere Ideen wäre ich dankbar. Danke für deine Hilfe und Ansätze Gruß Luki

Nein definitiv lokales Anmeldefenster... Die unterscheiden sich ja optisch, außerdem plopt das Fenster zu schnell auf für online. Aber ich hab auch schon das Onlinepasswort probiert. Und noch ein Nachtrag: Von Außerhalb kann ich Outlook konfigurieren bzw. die Handys und Laptops außerhalb der Domain funktionieren. Ich suche jetzt schon seit 2 Stunden meine falschen internen DNS Einträge. Aber jegliche Pings werden sauber aufgelöst.

Hallo Zusammen, ich hoffe alle hatten schöne Festtage. Ich war mal wieder damit beschäftigt einem Kunden die neue Serveranlage einzurichten. Soweit alles wie immer ohne größere Schwierigkeiten. Außer: Nach der Migration von Exchange 2016 zu Exchange 2019 plopt beim starten von Outlook die Kennwortabfrage auf. Das richtige Passwort bewirkt allerdings nur das genau diese Fenst45 wieder und wieder und wieder aufplopt. Zu den Umständen: Alter Server mit Server 2016 als DC Alter Server mit Server 2016 und Exchange 2016 Neuer Server mit Server 2022 als DC Neuer Server mit Server 2022 und Exchange 2019 Alle auf dem neusten Patchstand. Ausnahmslos Outlook in der Version 2021 also 2016 ;) , der Kunde hat 365 Lizenzen. DNS Einträge alle auf den neuen Exchange umgestellt. Die beiden alten laufen noch habe nur mal testweise den 2016 EX heruntergefahren. !!!!Der Login per OWA funktioniert einwandfrei!!!! Virtuelle Verzeichnisse sind identisch. Das richtige Zertifikat wird auch genutzt (öffentlich ausgestellt). Der Aufruf der Autodiscover.xml mit den Benutzerzugangsdaten funktioniert auch. Hat jemand einen Ansatz für mich? Gruß Luki p.s. die 2016 liefen bis dato Problemlos. Wir haben nur die gelegheit genutzt und mit der neuen Hardware auf den neustmöglichen

Hallo Zusammen, soooooooooo! Zuerst zu zahni: Das ist ein guter... ;) er bietet auch die Emulation an, sofern die Speichermedien es zulassen! Vor der Auswahl der Medien kann ich eine Emulation auswählen. Sobald ich die Medien ausgewählt habe, fehlt der Menüpunkt Emulation komplett. So wie ich es mir angelesen habe ist das auch normal so und es kommt auf den Chip an. INTEL SSD lassen beispielsweise eine Emulation ohne Neuformatierung zu. Mit JBOD-Mode oder AID-Mode hatte diese Problem nichts zu tun. Interessehalthalber werde ich mich aber auch da mal etwas belesen. Zur Lösung: Die Kabel sind endlich per Kurier angekommen. (Nachdem sowohl Transoflex als auch UPS die Pakete "verloren" haben.) NVME's bzw. die Backplane ans Mainboard angeschlossen und siehe da die Festplatten können mit dem ESXi kommunizieren, genau so wie es in dem Blog von WD beschrieben wurde. Neuformatierung durchgeführt und wieder an den RAID-Controller. Beim Erstellen des RAID's wurden die NVME's jetzt auch schon als 512er angezeigt und auch die Emulation war nach Auswahl der Medien noch verfügbar. Selbstverständlich hat der ESXi diese danach auch endlich als verfügbaren Datastore angezeigt. Als wenn nie was gewesen wären ;) Aber jetzt mal im Ernst. Ohne irgendwelche Hinweise kann das doch keiner wissen. Da muss WD oder VMware doch irgendwie drauf aufmerksam machen. Ich danke trotz alledem für die Hinweise und Lösungsansätze! Gruß Luki

Guten Morgen, der telefonische Support der einen ziemlich starken Akzent hatte ;) verwies mich leider nur auf das Ticket System auf der Internetseite. Da die Lizenz jedoch Brandneu ist dauert es bis diese auch für das Ticketsystem freigegeben ist........... leider. Jeder Dienstleister hat gerne einen sündhaft teuren Server bei sich rumstehen. Jedoch habe ich gemeinsam mit dem Serversupport der Firma Wortmann eine gewinnversprechende Lösung erarbeitet: - Es wurde getestet ob 4Kn Laufwerke vom ESXi wirklich Unterstützt werden... mit Intel und Samsung NVMEs ja. - Der Supportmitarbeiter hatte jedoch das selbe Problem mit dem Testsystem und den WD's wie wir. - Nachdem Wortmann dann kontakt zu WD hatte wurden wir auf folgenden Artikel hingewiesen: https://blog.westerndigital.com/formatting-4k-drives-for-vmware-vsphere/ Weitere Angaben hat WD in Richtung Wortmann nicht gemacht. - Leider helfen die Befehle jedoch nur etwas wenn die NVME's direkt ans Mainboard angeschlossen werden. Daher warten wir auf die passenden Anschlusskabel. - Ich bin gespannt ob die NVME's danach auch mit dem Raid-Controller laufen bzw. wir die Möglichkeit zur Emulation haben oder die Festplatten also 512er auftauchen. Sollte das des Problemes Lösung sein, wundere ich mich stark über die "Unwissenheit" bei VMware. Wenn schon nur ausgewählte Hardware unterstütz wird sollte doch mindestens ein Vermerk entweder im Guid oder beim Downloadportal des Treibers vorhanden sein. Ich kann mir nicht vorstellen das im allgemeinen bekannt sein sollte. Ich melde mich wieder sobald ich neuen Erkenntnisse habe.

Guten Morgen, also Firmware passte wirklich nicht zum Treiber.... Also sowohl auf den 8i also auch auf den 16i die Firmware auf 52.22.0-4544 angehoben. Treiber auch nochmal geprüft per cli 7.722.02.00-1OEM . Leider habe ich immer noch nicht die Möglichkeit den Datastore des 16i hinzuzufügen. ESXI auch nach dem FW testweise nochmals auf den HDD's im 8i neuinstalliert und auch bei beiden den Werkreset und das Raid gelöscht und neu erstellt. Spaßeshalber haben wir mal noch intakte Intel Intel® SSD DC P4510 (512e) eingebaut die noch im Lager dümpelten. DIESE WURDEN ERKANNT. Laut VMware sind aber auch die WD Supportet. Auch Dort habe ich nochmal die FW geprüft alles i.o. Noch einen Ansatz?

Mist, habe ich nur die FW vom 8i kontrolliert?! o.O Sobald ich morgen früh im Büro bin prüfe ich das nochmal! Vielen Dank für den Ansatz!

Siehe Nachtrag. Ja: https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=io&productid=49471&vcl=true Hersteller ist die Wortmann AG Bevor der Verweis an deren Support geht: Dieser hält sich außschließlich an die Vorgaben der freigegebenen Hardware und der BIOS und Firmwarekonfiguration. Einen Support für die Produkte von VMware selber haben die nicht. Sie verweisen uns regelmäßig an HyperV... Bisher kam das aber auf Grund der Erfahrung mit VMware nicht in Frage.

Laut dieser sind alle Komponenten kompatibel. Also bei Basiskomponenten weiß ich es da der Distributor VMWare Partner ist. Soll das in Klammern stehende heißen das die Platten nur für die vSAN's freigegeben ist dann überlege ich mir wirklich zu HyperV zu wechseln. https://www.vmware.com/resources/compatibility/detail.php?deviceCategory=vfrc&productid=50996&vcl=true Aber danke für deine Antwort. Nachtrag: Vertrauen ist gut, Kontrolle ist besser. Alle anderen Komponenten sind laut Guid Kompatibel und freigegeben für die Version. Einzig bei den NVME's ist der Zusatz in den Klammern in Benzug auf das vSAN. Aber das kann doch nicht sein das es nur dafür gilt oder?

Hallo Zusammen, erst einmal die Hardware: Mainbaord: Intel S2600STBR 2xLGA3647-0 CPU: 2x XEON Silver Raid-Controller: 1x BC MegaRAID 9560-8i , 1x BC MegaRAID 9560-16i Speicher: 2x Seagate 1.8TB (512e) am 8i, 4x WD ULTRASTAR SN640 1.92TB (4Kn) alles andere ist für das Problem schätzungsweise uninteressant... Alle Komponenten sollten von VMware unterstützt sein. Problem: Der ESXi erkennt das Raid 10 vom 16i nicht. Wie bin ich vorgegangen: Raid's erstellt sowohl mit Fast init als auch Full... (alle anderen werte bei Default belassen) Neustes 7.0.3 offline Bundle runtergeladen, aktuellsten Treiber für den bzw. die Controller von der VMWare Seite geladen (ist ja der selbe für 8i und 16i) Image mit Treibern per Shell erstellt und auf CD gebrannt. Installation: Das HDD-Raid vom 8i wird erkannt. Super. Wo ist das Raid 10 vom 16i? Auch im Webclient kann der Datastore nicht hinzugefügt werden der 16i wird aber unter Adapter genau wie der 8i aufgeführt. Dann kann der Treiber doch eigentlich nicht das Problem sein? (Vorausgesetzt der Treiber beinhaltet nicht generell Fehler mit dem 16i) Habe ich richtig recherchiert das die 4Kn für einen ESXi ab 6.7.x kein Problem mehr ist oder liegt da das Problem? Das ist bei weitem nicht mein erster Server mit ESXi und soweit ich mich erinnern kann auch nicht der erste mit NVME's. Ich weiß jedoch nicht mehr ob das 4Kn waren. Was ich schon getestet hab: - das selbe nur mit 6.7 U3 - auf einen USB Stick und Treiber nachinstalliert (selbes Ergebnis i8 Raid ist da das 16i Raid nicht) - Installation nur mit dem 16i. Gar kein Datastore zum installieren verfügbar (logischerweise wenn das Problem woanders herkommt) - Firmware des Mainboards, der Controller und der SSD's überprüft alles aktuell. - aus dem Raid 10 spaßeshalber 2x Raid 1 gemacht. Leider wurde davon auch kein Entweder es gibt doch eine Inkompatibilität und ich bin zu b***d zum Recherchieren oder ich sehe den Baum vor lauter Wäldern nicht. (oder so ;) ) Ich bin für jeden Ansatz dankbar! Gruß Luki

Ohoh! Da hatte ich wohl bisher glück das ich es nur bei 2016er machen musste o.O ... Naja hier ein Link: https://tkolber.medium.com/fixing-search-indexing-issues-within-exchange-2019-mailboxes-eba04d207312 Ich habe gerade mal auf die schnelle ein Testopfer gesucht aber leider keinen Gefunden bei dem nicht Indexierte Elemente vorhanden waren. Auf die 2. Option würde ich je nach Wissenstand zum Exchange verzichten. Die 3. Option scheint mir die am Erfolgversprechendste zu sein. Auch das wäre ja schnell erledigt und im Anschluss könnte man das betreffende Postfach auch testweise wieder zurück migrieren. Und die "Reparatur" Datenbank wieder löschen wenn es dann passt. Des Weiteren habe ich bei der Recherche zur Neuindexierung Exchange 2019 einige Foren gesehen bei denen Herausgekommen ist das es bis zur Version CU9 bzw. CU10 bekannte Probleme mit der Suche gab. Ich kann mich nicht genau erinnern ob das schon abgefragt wurde aber die neuste CU ist schon installiert???? p.s. Outlook 2016/2019 in Verbindung mit EX 2016/2019 scheinen die Fast Search Funktion zu favorisieren da ich über einen REG Eintrag gestolpert bin der genau das umstellt. Bei meinem Test hat der allerdings keine Auswirkungen auf meine Suche gehabt, daher würde ich mich nicht auf die Aussage versteifen.

Ich sehe aber keinen Beitrag worin steht das der Fast Search deaktiviert ist. (Zumal mir kein Anwendungsfall einfallen würde warum man das aktiv deaktivieren sollte) Des Weiteren steht in dem Link auch nicht die Reihenfolgen. Wird erst der Offlinecache abgefragt oder erst der Exchange. Ich tippe (ohne es genau zu wissen) mal auf den Exchange. Was dann alles wieder auf meinen Eingangsbeitrag schließen lässt: Da ist bestimmt etwas mit der Suchdatenbank nicht i.o. -> Neuerstellen ist Kinderleicht braucht nur etwas Zeit... einfach Freitagabend anstoßen und Montags das Resultat betrachten. Alles andere wäre aufwand am Client selber.... also Kontakt mit dem User..... Grrrrrrrrrrr ;)