magicpeter

Ja könnte aber noch was besser sein... :D

Ja, nach dem die Failover-Partnerschaft aufgelöst war hat der Sekundäre DHCP wieder aus dem gesamten Bereich IP-Adressen verteilt.

Sorry, bin wie immer im Stress.... Danke, für den Hinweis... :)

Um das hier noch einmal richtig zu stellen. Gerade alles durch gespielt. Es hat sehr gut funktioniert. Primären DHCP mit dem Sekundären DHCP im Failover verbunden Hot Standby. Primären DHCP abgeschaltet und der Sekundäre DCHP hat die Arbeit übernommen. DHCP Failover Beziehung entfernen über die PowerShell Remove-DhcpServerv4Failover -Name serverdc.domain.local-serverdc2.domain.local -Force Danach ist der Sekundäre DHCP der alleinige Herrscher über die IP-Adressen. Fertig und aus.

Ja, der Sekundäre DHCP weiss das der Primäre DHPC Down ist. Ja, es geht sich um den Post. Ich werde jetzt die Failover Partnerschaft auflösen und gut ist.

Ok, was ich jetzt raushöre es hat noch keiner jemals gemacht. Schade, dann werde ich das wohl machen. Ich sag euch dann Bescheid. Was mich noch interessieren würde, wenn der primäre DHCP down ist dann muss man dich dem sekundären DHCP sagen können das er jetzt der Chef ist. Das muss MS doch vorgesehen haben. Nicht immer kann der primäre DHCP wiederbelebt werden.

Der Befehl soll ja nicht am nicht mehr vorhandenen Primären DHCP Server ändern. Der ist ja nicht mehr da. Ich führe den Befehl auf dem Sekundären DHCP aus und löse damit die Failover-Partnerschaft auf. Da es den Primären DHCP Server nicht mehr gibt ist alles OK. Würde ich jetzt annehmen. Oderrrr? Der Sekundäre DHCP ist auch Domaincontroller und DNS. Er kann also allein herrschen. :D

Sauber diese Antwort... Hilft leider überhaupt nicht weiter. Ich danke dir trotzdem für deine Zeit. Kann man machen, aber wenn es schon einmal jemand gemacht hat, kann man auch einmal fragen. Anstatt alles im Testlab nachzubauen. :D

Hi Martin, und wohin damit in den GPOs? Danke Dir...

Hi und Moin, ich habe ein Windows 2012 Netzwerk mit 2 DHCP Servern 2012 im Failover mit Hot Standby. Jetzt ist der Primäre DHCP Server ausgefallen und kommt auch nicht wieder. Der Sekundäre DHCP hat das erkannt und den Partnerserver in den Status "Server Down" versetzt. Alles gut. Aber wie sage ich dem Sekundären DHCP jetzt das er ab jetzt der Alleinverantwortliche DHCP Server ist und alle IP-Adresse zum verteilen nutzen darf und nicht nur die 5%. Und die Leases wieder 4 Tage und nicht nur 1 Stunde dauern sollen. Die Failover-Partyschaft kann ja gelöscht werden weil der Primäre DHCP Server nicht mehr wieder kommt. Kann ich einfach so die Failover-Partnerschaft in der DHCP Konsole löschen? Danke euch... Ich habe einmal ein bisschen gegoogletet... PowerShell: Remove-DhcpServerv4Failover -Name serverdc.domain.local-serverdc2.domain.local -Force Bleibt denn dann der Scope auf dem Sekundäre Server erhalten und der Sekundäre Server ist der alleinige DHCP?

Hi lefg, wie machst du das denn per GPO? Aber es ist schon etwas fragwürdig GPOs mit GPOs zubeschleunigen. :D Aber wenns geht... (o;

Stimmt habe ich jetzt auch an einigen PCs gesehen. Kann man irgendwie den Befehl "gpupdate /force" auch per Remote auf allen PCs anstossen? Es gibt kein Loginscript bei uns. Wir machen alles über GPOs.

Hat super geklappt. Auf dem neue ServerDC2 den WSUS eingerichtet und konfiguriert. Dann den neuen WSUS - Server in die GPO eingetragen und fertig. http://mntechblog.de/artikelserie-windows-server-update-services-wsus-unter-windows-server-2012-installieren-und-konfigurieren/

Oder den DNS-Server auf dem Host richtig eintragen... :D

Moin, kurze Rückmeldung. Hat Super geklappt, In der Druckerverwaltung auf dem ServerDC die Drucker exportiert. Auf dem neuen ServerDC2 die Druckerverwaltung installiert und die Drucker importiert. https://wolfgangontheroad.wordpress.com/2008/06/10/213-druckermigration-windows-server-2008-style/ Dann die Drucker durch eine Gruppenrichtlinie an Clients verteilt. http://mntechblog.de/drucker-durch-eine-gruppenrichtlinie-an-clients-verteilen/ Alte Drucker auf den Client deinstalliert, während dessen kamen schon die neuen Drucker bei den Clients an. Einfach super...

Update zur Zeitsynchronisation des Hypes-V Host. Wenn der Host nicht in der Domain ist, dann kann natürlich der Serviername "SERVERDC.domain.local" nicht für die Auflösung genommen werden. Trage dann dort die IP-Adresse des Servers ein und gut ist.

Das hat keiner gesagt. Ich kenne wir die wir die IT am Laufen halten, haben immer etwas Stress, Es kommt auch immer auf die Anzahl der Kunden an die man aktuell betreut oder betreuen muss. :D Auch das ist ein Grund für Stress. In der Ruhe liegt die Kraft.

Sorry, stimmt aber ich bin immer so im Stress.... Gefunden: https://social.technet.microsoft.com/Forums/de-DE/b60656f1-7e47-48b7-841b-2796c4b67e3e/wsus-auf-neuen-server-umziehen?forum=windows_Serverde

Kannst du mir sagen wie das das gemacht hast? Danke dir, aber ein bisschen genauer wäre schon hilfreich.

Ja, das habe ich auch schon gemacht. Hast du danach den Exchange Information Dienst (ExchangeHM) neugestartet? Werde ich heute Abend noch eimal testen. Geht leider nicht tagsüber. Wie änderst Du denn am Konrektor die Berechtigung und was hast du eingestellt damit das funktioniert? Würde mich echt mal interessieren. Vielleicht löst das ja das Problem. Dank Dir schon mal für deine Zeit.

Hi Peter, das Schema Update ist sauber durchgelaufen und das Exchange Upgrade CU8 auch. Kann natürlich sein, aber was nun? Der Exchange läuft bis auf die 5 Events im Log. Ich werde noch einmal recherchieren. Update: Zu dmn Event <<< Quelle: Schannel ID: 36888 Ebene: Fehler Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 10. Der Windows-SChannel-Fehlerstatus lautet: 1203 <<< konnte ich folgenden Post finden: https://social.technet.microsoft.com/Forums/de-DE/374d7a25-9980-4470-9fc8-86a0ae9c6b07/schannel-error-36888-fehlerstatus-1203?forum=exchange_serverde Es scheint so als könnte man das vernachlässigen. Update: Zu dem Event <<< Quelle: MSExchangeTransport ID: 5016 Ebene: Fehler Microsoft Exchange konnte keine Route zum Connector 'CN=Windows SBS Company Web Connector SERVER,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local' in Routingtabellen mit dem Zeitstempel 27.04.2015 04:16:21 erkennen. Dieser Connector wird nicht verwendet. Gesamtanzahl Quellserver: 1; Anzahl unbekannter Server: 1; Anzahl Quellserver ohne Routing: 0; Anzahl inaktiver Quellserver: 0. <<< Das schein ein Überbleibsel aus der Migration vom SBS 2008 vor 2 Jahren zu sein. Es gibt keinen Empfangs- oder Sendeconnect mit diesem Namen in Exchange 2013. Ich glaube ich werde diesen Connector mit Hilfe des ADSIEDIT entfernen. https://social.technet.microsoft.com/Forums/exchange/en-US/3e90f25c-67b3-4507-ade0-7ae513d852a6/do-i-need-windows-sbs-company-web-connector-servername-event-ids-5015-5016?forum=exchange2010 http://blogs.technet.com/b/canitpro/archive/2007/01/04/your-solutions-fix-exchange-2007-smtp-connectors-with-adsiedit.aspx

Ja, komisch. Die Servierzeit stimmt aber. Wie kann das sein? Kann es sein das eine Nachricht in der Warteschlange steckte oder?

Hallo Daniel, danke, diesen Post habe ich auch schon gefunden. Ich habe jetzt als erstes einmal die Health-Konto im AD gelöscht und den Health-Dienst neugestartet. Die Konten wurden wieder neuerstellt, aber der Eintrag im Eventlog blieb der gleiche. Dann haben ich über die Active Directory Domänen und Vertrauensstellungen" die UPN Suffixe für die Gesamtstruktur (Forest) gepflegt und die Kundendomain.de hinzugefügt und den Health-Konten im AD als UPN eingestellt. Der Fehler im Eventlog tritt jetzt nicht mehr auf. Es erscheinen jetzt aber noch ein paar Warnungen & Fehler die es vorher nicht gab. Quelle: MSExchangeFrontEndTransport ID: 1035 Ebene: Warnung Fehler LogonDenied bei der eingehenden Authentifizierung für den Empfangsconnector Client Frontend SERVEREX. Der Authentifizierungsmechanismus ist Login. Die Quell-IP-Adresse des Clients, der die Authentifizierung bei Microsoft Exchange versucht hat, ist [127.0.0.1]. Quelle: Perflib ID: 1023 Ebene: Fehler Die erweiterbare Leistungsindikator-DLL MSExchangeIS kann nicht geladen werden. Die ersten vier Bytes (DWORD) des Datenbereichs enthalten den Windows-Fehlercode. Quelle: MSExchangeTransport ID: 5016 Ebene: Fehler Microsoft Exchange konnte keine Route zum Connector 'CN=Windows SBS Company Web Connector SERVER,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local' in Routingtabellen mit dem Zeitstempel 27.04.2015 04:16:21 erkennen. Dieser Connector wird nicht verwendet. Gesamtanzahl Quellserver: 1; Anzahl unbekannter Server: 1; Anzahl Quellserver ohne Routing: 0; Anzahl inaktiver Quellserver: 0. Quelle: MSExchangeIS ID: 4001 Ebene: Warnung Microsoft Exchange Information Store service has encountered a message (internet message id <f02859f5b6354c689661bd71ef8a7e4f@SERVEREX.domain.local>) with an invalid submit time (28.05.2015 04:00:32). Duplicate copies of this message may be delivered. Quelle: Schannel ID: 36888 Ebene: Fehler Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 10. Der Windows-SChannel-Fehlerstatus lautet: 1203 Quelle: MSExchange CmdletLogs ID: 8 Ebene: Fehler (PID 4060, Thread 19) Task "Get-HealthReport" löst einen Ausnahmefehler aus: System.ArgumentException: sessionState bei Microsoft.Exchange.Configuration.Tasks.ExchangePropertyContainer.GetProvisioningBroker(ISessionState sessionState) bei Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlersImpl(Task task) bei Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlers(Task task) bei Microsoft.Exchange.Configuration.Tasks.Task.<BeginProcessing>b__4() bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeNonRetryableFunc(Action func, Boolean terminatePipelineIfFailed). Wie gesagt, der Server funktioniert einwandfrei, nur würde ich gerne den Eventlog bereinigen. Vor dem Update auf CU8 war das Eventlog sauber. Danke für deine Hilfe. Oh, mir ist jetzt bei der Überprüfung des Systems noch etwas im Aktive Direktory aufgefallen: Aktuelle: Domainfunktionsebene: Windows Server 2003 Sollte ich das besser auf Windows Server 2012 R2 heraufrufen? Es ist ein DC mit Windows 2012 R2 und ein alter mit Windows 2012 vorhanden.

Hi DocData, danke für die Info, sorry habe ich heute einfach übersehen. Ich habe die Domain schon raus genommen. Kannst du Domain bitte auch gegen Domain.local in deinem Post tauschen. Danke. Ich habe einmal über den OWA eine E-Mail gesendet und das kam zurück. Fehler bei der Nachrichtenzustellung an folgende Empfänger oder Gruppen: HealthMailbox762f9cc084a24c0b95ef2cee864efab7@domain.local (HealthMailbox762f9cc084a24c0b95ef2cee864efab7@domain.local) Die eingegebene E-Mail-Adresse konnte nicht gefunden werden. Überprüfen Sie die E-Mail-Adresse des Empfängers, und versuchen Sie, die Nachricht erneut zu senden. Wenden Sie sich an den Helpdesk, falls das Problem weiterhin besteht. Generierender Server: SERVEREX.domain.local HealthMailbox762f9cc084a24c0b95ef2cee864efab7@domain.local Remote Server returned '550 5.1.1 RESOLVER.ADR.RecipNotFound; not found' Ich werde einmal die Health E-Mail-Adressen überprüfen. Ich denke da liegt das Problem. Fällt dir noch was ein.

Hi, wir haben heute einen Windows 2012 Standard Server mit Exchange 2013 CU2 auf CU8 upgegradet. Hat alles sehr gut geklappt. Keine Fehler bei der Installation. Der Exchange läuft und empfängt und sendet emails. Alles gut soweit. Nur im Eventlog sind einige Fehlermeldungen aufgetreten die sich alle 5 Minuten wiederholen. Quelle: MSExchange CmdletLogs ID: 8 Ebene: Fehler (PID 4060, Thread 19) Task "Get-HealthReport" löst einen Ausnahmefehler aus: System.ArgumentException: sessionState bei Microsoft.Exchange.Configuration.Tasks.ExchangePropertyContainer.GetProvisioningBroker(ISessionState sessionState) bei Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlersImpl(Task task) bei Microsoft.Exchange.Provisioning.ProvisioningLayer.GetProvisioningHandlers(Task task) bei Microsoft.Exchange.Configuration.Tasks.Task.<BeginProcessing>b__4() bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeNonRetryableFunc(Action func, Boolean terminatePipelineIfFailed). Quelle: MSExchangeTransport ID: 1025 Ebene: Fehler SMTP hat eine (P1)-E-Mail von "HealthMailbox762f9cc084a24c0b95ef2cee864efab7@domain.local" mit dem Connector "Client Proxy SERVEREX" zurückgewiesen, und der Benutzer hat sich als "HealthMailbox762f9cc084a24c0b95ef2cee864efab7" authentifiziert. Der Active Directory-Lookupvorgang nach der Absenderadresse gab Überprüfungsfehler zurück. Microsoft.Exchange.Data.ProviderError In Google habe ich gesehen das seiner die gleichen Meldungen hatte und mit dem Befehl die Anzeige einfach abgeschaltet hat. Add-GlobalMonitoringOverride -Identity "FrontendTransport\OnPremisesSmtpClientSubmission" -PropertyName Enabled -PropertyValue 0 -ApplyVersion "15.0.1076.9" -ItemType Monitor Aber das ist ja keine wirklich Lösung oder? Kenn jemand diese Meldungen und ist der angegebene Lösung wirklich der richtige? Noch neuen schönen Sonntag. Bis bald...