EDV11

Ja wie gesagt schon gelesen. Die Frage ist ja nur ob ich den Hybrid Assistenten nochmal durchführen muss am neuen EX 19 nix anderes Davon ausgegangen das ich die Exchange Verwaltungskonsole weiterhin nutzen möchte und nicht nur die Shell Befehle.

Hatte ich gelesen......

Danke euch beiden! Das ist mir schon klar. Aber brauche ich noch den Hybrid Zustand oder reicht es einfach einen Exchange im Netz zu haben? Im Azure AD Connect ist jetzt noch der Hybrid Modus gesetzt. Würdet ihr das lassen?

Hallo zusammen, habe aktuell noch einen Exchange 2013 CU 23 der im Hybrid Modus läuft. Postfächer sind bereits alle zu Exchange Online umgezogen. Läuft auch alles einwandfrei. Jetzt würde ich gerne den alten Exchange inkl. Server 2012R2 loswerden wegen Support Ende. Mit dem Exchange 2019 CU 12 ist ja wieder eine Lizenz dabei für den Hybrid Modus. AD Sync läuft und das ich die AD Objekte nicht verliere will ich den lokalen Exchange behalten. Wenn ich das richtig gelesen habe könnte ich ja sogar den Hybrid Status auflösen oder? Möchte ja nur noch die AD Objekte verwalten können. Ich würde jetzt wie folgt vorgehen. Server 2019 installieren danach Exchange 2019 CU 12 installieren soweit kein Problem. Muss ich danach nochmal den Hybrid Wizard ausführen oder reicht es wenn der Exchange einfach läuft? Wie muss ich den alten Exchange 2013 deinstallieren erst den Hybrid Modus auflösen? Danke für euren Input. Grüße EDV11

Noch eine Ergänzung die mir aufgefallen ist: Wenn ich das Setup mit folgenden Befehl in einer Shell starte: setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms Kommt folgende Fehlermeldung: [ERROR] Setup encountered a problem while validating the state of Active Directory: Die Active Directory-Schemaversion (17003) ist höher als die Version von Setup (17002). Daher kann der Befehl 'PrepareSchema' nicht ausgeführt werden. See the Exchange setup log for more information on this error. Was mir dabei auffält ist folgende Zeile aus der Log Datei: [07.04.2021 08:45:04.0955] [0] Starting Microsoft Exchange Server 2019 Setup [07.04.2021 08:45:04.0955] [0] ********************************************** [07.04.2021 08:45:04.0956] [0] Local time zone: (UTC+01:00) Amsterdam, Berlin, Bern, Rom, Stockholm, Wien. [07.04.2021 08:45:04.0956] [0] Operating system version: Microsoft Windows NT 6.2.9200.0. [07.04.2021 08:45:04.0957] [0] Setup version: 15.2.858.12. Das ist doch die Setup Version von CU 9 und ich verwende definitiv ein Setup von CU 10 und habe das Iso auch gerade nochmal frisch heruntergeladen. Wie kann das sein? Temp Ordner etc. habe ich bereinigt.

Servus zusammen, bei einem Exchange Server aktueller Stand: EX 19 CU9 bekomme ich beim Setup von CU 10 bei Schritt 1 folgenden Fehler: Der folgende Fehler wurde generiert, als "$error.Clear(); $createTenantRoot = ($RoleIsDatacenter -or $RoleIsPartnerHosted); $createMsoSyncRoot = $RoleIsDatacenter; #$RoleDatacenterIsManagementForest is set only in Datacenter deployment; interpret its absense as $false [bool]$isManagementForest = ($RoleDatacenterIsManagementForest -eq $true); if ($RolePrepareAllDomains) { initialize-DomainPermissions -AllDomains:$true -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest; } elseif ($RoleDomain -ne $null) { initialize-DomainPermissions -Domain $RoleDomain -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest; } else { initialize-DomainPermissions -CreateTenantRoot:$createTenantRoot -CreateMsoSyncRoot:$createMsoSyncRoot -IsManagementForest:$isManagementForest; } " ausgeführt wurde: "System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei Microsoft.Exchange.Management.Tasks.SetupTaskBase.LogReadObject(ADRawEntry obj) bei Microsoft.Exchange.Management.Tasks.InitializeDomainPermissions.InternalProcessRecord() bei Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecord>b__91_1() bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed) bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessTaskStage(TaskStage taskStage, Action initFunc, Action mainFunc, Action completeFunc) bei Microsoft.Exchange.Configuration.Tasks.Task.ProcessRecord() bei System.Management.Automation.CommandProcessor.ProcessRecord()". Der Server läuft einwandfrei und Virenscanner etc. sind alle vor der Installation deaktiviert worden. Könnt Ihr mir helfen? Vielen Dank. Grüße

Vielen Dank für euren Input. Jetzt ist mir klar geworden wie die Updates zusammenhängen. VCenter Update spiele ich über die Appliance gleich mal ein damit ist die Lücke geschlossen. Update vom Host ziehe ich dann die Tage nach. Euch allen noch ein schönes Wochenende.

OK aber das wäre ja kein Problem oder... Sonst würde das doch gar nicht angeboten werden. Im Kommentar von meinem verlinkten Artikel wurde es anscheinend so auch gemacht.

Liege ich richtig wenn ich über die vCenter Server Appliance das Update einspiele? Letzte Version wäre dann die 6.7.4800 und diese Version müsste alle Patches beinhaltet haben?

Ja ist ein einzelner Host ohne Cluster. vCenter finde ich wie raus???

Hallo zusammen, habe hier einen ESXI 6.7.0 Update 1 (Build 10302608) Server. Der vSphere Client hat die Version 6.7.0.47000. Da ich ganz neu im Thema VMWare bin und diesen Artikel gelesen habe: https://www.borncity.com/blog/2021/05/27/schwachstelle-cve-2021-21985-in-vsphere-client-patchen/ wollte ich die Umgebung patchen. Leider fehlt mir ehrlich gesagt das Wissen wie das Ganze funktioniert. Könnt Ihr mich unterstützen und Tipps geben was zu beachten ist? Hatte bis jetzt noch keine Berührungspunkte mit VMWare da ich aus dem Hyper-V Lager komme. Vielen Dank! Grüße EDV11

@heuchler Vielleicht auch eine Idee: https://www.fujitsu.com/de/products/computing/pc/tablets/stylistic-q5010/ Grüße

@testperson Danke für die Info! Wurde schon erledigt am We. Verzeichnisse wurden geprüft und MSERT ist auch gelaufen ohne Funde.

@testperson Danke für die Info hatte ich noch nicht gelesen. Aktuell sieht auch alles gut aus nochmal Glück gehabt!

Hallo zusammen, habe das PowerShell Script auch auf einem Server laufen lassen. Beim Punkt: CVE-2021-26855 findet er einen Eintrag. Im abgelegten Log File findet sich folgender Eintrag: "2021-03-03T07:39:36.752Z","ServerInfo~a]@exchange.contoso.intern:444/autodiscover/autodiscover.xml?#" Haben dann im Ordner: C:\Program Files\Microsoft\Exchange Server\V15\Logging\Autodiscover eine Log Datei gefunden die den richtigen Zeitstempel hat. Im Eintrag stand der der Benutzer administrator@contoso.intern nicht gefunden wurde. Muss ich mir sorgen machen oder ist das unbedenklich? Grüße

Guten Morgen, wollte kurz mitteilen das ich den Fehler gefunden habe. Die betroffene Adresse war im Journaling eingestellt für nicht zustellbare Berichte. Gutes neues Jahr allen noch!

Ja ich weiß hast ja auch Recht! Ticket ist raus...

Hallo zusammen, habe einen O365 Tenant mit 8 Exchange Online Plan 1 Abos. Es funktioniert alles einwandfrei bis auf 1 Sache. Bei einem Postfach können die Automatischen Antworten über das lokale Outlook oder auch per OWA gesetzt werden nur leider wird weder intern noch extern eine Antwort versendet. Bei allen anderen Postfächern funktioniert dies einwandfrei. Folgende Sachen habe ich bis jetzt zur Fehlerbehebung durchgeführt. - grundsätzlich einmal geprüft ob der Abwessenheitsassistent richtig konfiguriert wurde - per PowerShell geprüft ob im Postfach der Abwessenheitsassistent ankommt und ob die Werte passen. Sieht alles vernüftig und richtig aus - diese Anleitung durchgegangen: https://www.frankysweb.de/exchange-abwesenheitsnachrichten-werden-nicht-verschickt/ - verschiedene Email Adressen probiert nicht das schon eine der Adressen eine Benachrichtigung erhalten hat (wird ja nur 1x versendet pro Empfänger) - neues Outlook Profil/Automatische Antworten online im OWA gesetzt. Bin mit meinem Latein schön langsam am Ende und wollte einfach mal hören ob Ihr eine Idee hättet oder jemand vielleicht das Problem schon einmal hatte. Support Ticket würde ich sonst am Montag eröffnen da mir persönlich nix mehr einfällt. Vielen Dank an Alle und noch schöne Weihnachten! Grüße

Guten Morgen Mike, ja habe die Logs schon durchgeschaut aber dort ist nix besonderes zu finden... Hast du das Problem denn in deiner Umgebung? Gruß EDV11

Firefox Profile, Email Signatur sind z.B. solche Themen. RDP Server könnte das Problem lösen...

Hallo Jan, in diesem Fall leider mehrmals am Tag..und ehrlich Folder Redirection ist auch nicht das ware. Gibt da ja auch so manche Probleme. Gruß EDV11

Hallo zusammen, kurzer Überblick über die Struktur: Client ist ein Windows 10 1909 letzter Patchstand mit Realtek Netzwerkkarte und Trend Micro WFBS Agent. Server ist ein Server 2016 Standard letzter Patchstand mit Intel Netzwerkkarte. Eingesetzt werden Roaming Profile dies funktioniert auch super bis auf 1 Fehler. Wird am Client ein Neustart durchgeführt und die erneute Anmeldung durchgeführt dauert dies deutlich länger wie üblich und es erscheint dann die Meldung das ein Temporäres Profil geladen wurde. Verlinke euch mal folgende Seite dort ist der Fehler auch beschrieben: https://helgeklein.com/blog/2016/04/windows-10-roaming-profile-sharing-v ... Habe die Lösungswege schon alle probiert ohne Erfolg. Virenscanner wurde bereits deinstalliert. Die einzige Lösung die wirklich Abhilfe brachte war das deaktivieren der Windows Firewall. Ist diese deaktiviert funktioniert der Neustart mit erneuter Anmeldung immer einwandfrei. Da ich natürlich die Firewall nicht dauerhaft deaktivieren möchte wollte ich euch fragen ob jemand von euch das Problem bereits hatte und lösen konnte? Bin gespannt auf eure Antworten. Grüße EDV11 P.S. Verweise darauf das ich das Thema auch im Administrator.de Forum gepostet habe.

Guten Morgen, die Lösung ist die GPO anzupassen... Open gpedit.msc (Group Policy Editor) Browse to Computer Configuration->Windows Settings->Security Settings->Local Policies->Security Options Enable “User Account Control: Admin Approval Mode for the Built-in Administrator account”, Restart Server Grüße EDV11

Hallo, ich hatte den Fehler erst bei einem Fujitsu TX140S1. Der Server hatte den Fujitsu D2616 512MB Cache Controller. Es tratt genau der gleiche Fehler auf und dort war es das Bios des Raid Controllers. Das wurde auf die aktuelle Version geupdatet und seit dem läuft alles wieder einwandfrei. Vielleicht konnte ich ja helfen.

Hallo Chris, das ist ein bekannter Fehler von der installierten Emailsoftware vom HTC Desire. Soll laut HTC mit dem nächtsten Update auf Android 4.0 gelöst werden. Ich würde dir als Ersatz die Software Touchdown für Android empfehlen, ist eine echt gute App. Schau es dir mal an. Gruß EDV11