Jump to content

winRM funktioniert nicht mehr


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

 

Ob es wohl sinnvoll ist, auf einen WinRM-Fehler zu bestehen, obwohl WinRM auf dem Server funktioniert?

Ob es wohl sinnvoll ist, die Antwort von Blub in Frage zu stellen ohne sie 1. getestet zu haben oder 2. sie technisch mit Fachwissen bewerten zu können?

 

"Der Fehler ist doch eindeutig" Fehler sind in der IT-Welt selten eindeutig, besonders wenn diese noch dazu Übersetzt worden sind.  ;)

 

Erkläre doch bitte mal dein Vorgehen strukturiert. Also aus welchem Grund du was tust und dir davon erwartest. Verstehe das bitte nicht falsch.. Es ist wirklich schwierig Dir zu folgen, weil du dich selbst mit deinen Handlungen nicht erklärst, geschweige denn die genannten Hilfestellungen umsetzt. Warum sollte Dir dann noch jemand hier helfen, wenn die Antwort der Kollegen eh nicht für ernst genommen wird  :confused:  ;)

 

Probier´s mal auf dem DC mit "dcdiag" und analysiere die Fehler...

 Ich suche den Fehler das ist was ich tue. Fakt ist der Dienst lässt sich nicht starten was ja wohl klar mit dem Fehler zu tun hat, dass Kerberos nicht geht. Nun muss ich den Dienst reparieren das ist meine Vorgehen.

 

Wo nehme ich die Hilfestellung nicht ernst? Habe bisher alles ausprobiert wo man mir gesagt hat zu machen...

 

dcdiag zeigt mir auch wieder diesen Kerberos als Problem an sowie nun weitere Probleme seit ich mit Kerberos zu kämpfen habe. Unter anderem funktioniert der RPC-Server nicht mehr. Ich selber kann da nichts machen darum habe ich hier um Rat gefragt. Hier dcdiag:

PS C:\Users\Administrator> dcdiag

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = testsrv2
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\TESTSRV2
      Starting test: Connectivity
         ......................... TESTSRV2 hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\TESTSRV2
      Starting test: Advertising
         ......................... TESTSRV2 hat den Test Advertising bestanden.
      Starting test: FrsEvent
         ......................... TESTSRV2 hat den Test FrsEvent bestanden.
      Starting test: DFSREvent
         Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
         vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
         ......................... Der Test DFSREvent für TESTSRV2 ist fehlgeschlagen.
      Starting test: SysVolCheck
         ......................... TESTSRV2 hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... TESTSRV2 hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... TESTSRV2 hat den Test KnowsOfRoleHolders bestanden.
      Starting test: MachineAccount
         ......................... TESTSRV2 hat den Test MachineAccount bestanden.
      Starting test: NCSecDesc
         ......................... TESTSRV2 hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         ......................... TESTSRV2 hat den Test NetLogons bestanden.
      Starting test: ObjectsReplicated
         ......................... TESTSRV2 hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         [Replications Check,TESTSRV2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von TESTSRV3 nach TESTSRV2
            Namenskontext: DC=ForestDnsZones,DC=deb,DC=test
            Beim Replizieren ist ein Fehler aufgetreten (1256):
            Der Remotecomputer ist nicht verfügbar. Weitere Informationen zur Behebung von Netzwerkproblemen finden Sie
in der Windows-Hilfe.

            Auftreten des Fehlers: 2016-03-29 16:48:08.
            Letzter erfolgreicher Vorgang: 2015-12-20 12:01:41.
            Seit dem letzten erfolgreichen Vorgang sind 301 Fehler aufgetreten.
         [TESTSRV3] DsBindWithSpnEx()-Fehler -2146893022,
         Der Zielprinzipalname ist falsch..
         [Replications Check,TESTSRV2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von TESTSRV3 nach TESTSRV2
            Namenskontext: DC=DomainDnsZones,DC=deb,DC=test
            Beim Replizieren ist ein Fehler aufgetreten (1256):
            Der Remotecomputer ist nicht verfügbar. Weitere Informationen zur Behebung von Netzwerkproblemen finden Sie
in der Windows-Hilfe.

            Auftreten des Fehlers: 2016-03-29 16:48:08.
            Letzter erfolgreicher Vorgang: 2015-12-20 12:01:38.
            Seit dem letzten erfolgreichen Vorgang sind 301 Fehler aufgetreten.
         [Replications Check,TESTSRV2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von TESTSRV3 nach TESTSRV2
            Namenskontext: CN=Schema,CN=Configuration,DC=deb,DC=test
            Beim Replizieren ist ein Fehler aufgetreten (-2146893022):
            Der Zielprinzipalname ist falsch.
            Auftreten des Fehlers: 2016-03-29 16:48:08.
            Letzter erfolgreicher Vorgang: 2015-11-18 18:54:23.
            Seit dem letzten erfolgreichen Vorgang sind 302 Fehler aufgetreten.
         [Replications Check,TESTSRV2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von TESTSRV3 nach TESTSRV2
            Namenskontext: CN=Configuration,DC=deb,DC=test
            Beim Replizieren ist ein Fehler aufgetreten (-2146893022):
            Der Zielprinzipalname ist falsch.
            Auftreten des Fehlers: 2016-03-29 16:48:08.
            Letzter erfolgreicher Vorgang: 2015-12-20 12:01:34.
            Seit dem letzten erfolgreichen Vorgang sind 300 Fehler aufgetreten.
         [Replications Check,TESTSRV2] Bei einer kürzlich ausgeführten Replikation ist ein Fehler aufgetreten:
            Von TESTSRV3 nach TESTSRV2
            Namenskontext: DC=deb,DC=test
            Beim Replizieren ist ein Fehler aufgetreten (-2146893022):
            Der Zielprinzipalname ist falsch.
            Auftreten des Fehlers: 2016-03-29 16:48:08.
            Letzter erfolgreicher Vorgang: 2015-12-20 12:05:36.
            Seit dem letzten erfolgreichen Vorgang sind 301 Fehler aufgetreten.
         ......................... Der Test Replications für TESTSRV2 ist fehlgeschlagen.
      Starting test: RidManager
         ......................... TESTSRV2 hat den Test RidManager bestanden.
      Starting test: Services
         ......................... TESTSRV2 hat den Test Services bestanden.
      Starting test: SystemLog
         Fehler. Ereignis-ID: 0x40000004
            Erstellungszeitpunkt: 03/29/2016   16:19:59
            Ereigniszeichenfolge:
            Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zi
elname war HTTP/testsrv3.deb.test. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token n
icht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert
ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Serv
er verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort ü
bereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, das
s der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Serve
rname nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Clientdomäne (DEB.TEST) unterscheidet,
 prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollquali
fizierten Namen, um den Server zu identifizieren.
         Fehler. Ereignis-ID: 0x40000004
            Erstellungszeitpunkt: 03/29/2016   16:20:14
            Ereigniszeichenfolge:
            Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zi
elname war ldap/testsrv3.deb.test. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token n
icht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert
ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Serv
er verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort ü
bereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, das
s der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Serve
rname nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Clientdomäne (DEB.TEST) unterscheidet,
 prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollquali
fizierten Namen, um den Server zu identifizieren.
         Fehler. Ereignis-ID: 0x40000004
            Erstellungszeitpunkt: 03/29/2016   16:48:08
            Ereigniszeichenfolge:
            Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zi
elname war E3514235-4B06-11D1-AB04-00C04FC2DCD2/1d56f52f-7291-45ba-8501-59fd4668872c/deb.test@deb.test. Dies deute
t darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten,
wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie s
icher, dass der Ziel-SPN nur bei dem Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftr
eten, wenn das Kennwort für das Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribut
ion Center) für den Zieldienst konfiguriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für
 die Verwendung des gleichen Kennworts konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zi
eldomäne (DEB.TEST) von der Clientdomäne (DEB.TEST) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Se
rverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren
.
         Fehler. Ereignis-ID: 0x40000004
            Erstellungszeitpunkt: 03/29/2016   17:09:55
            Ereigniszeichenfolge:
            Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zi
elname war LDAP/1d56f52f-7291-45ba-8501-59fd4668872c._msdcs.deb.test. Dies deutet darauf hin, dass der Zielserver das
 vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SP
N) nicht bei dem Konto registriert ist, das der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN nur bei dem
Konto registriert ist, das vom Server verwendet wird. Dieser Fehler kann auch auftreten, wenn das Kennwort für das Zield
ienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution Center) für den Zieldienst konfig
uriert ist. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des gleichen Kennwort
s konfiguriert sind. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Client
domäne (DEB.TEST) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinde
n, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
         ......................... Der Test SystemLog für TESTSRV2 ist fehlgeschlagen.
      Starting test: VerifyReferences
         ......................... TESTSRV2 hat den Test VerifyReferences bestanden.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: deb
      Starting test: CheckSDRefDom
         ......................... deb hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... deb hat den Test CrossRefValidation bestanden.

   Unternehmenstests werden ausgeführt auf: deb.test
      Starting test: LocatorCheck
         ......................... deb.test hat den Test LocatorCheck bestanden.
      Starting test: Intersite
         ......................... deb.test hat den Test Intersite bestanden.
PS C:\Users\Administrator>

Hier auch wieder Kerberos welches nicht geht und ein Replikaionsproblem. Bevor Kerberos ging gab es soviel ich weiss auch nie Repalikationsproble

Link zu diesem Kommentar
  • 4 Wochen später...

Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Client
domäne (DEB.TEST)
unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinde
n
, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.

 

Hast du bei Änderung deines IP-Konzepts die Registrierung in der Domäne deaktiviert?

Ich lese das alles nicht nochmal, ist deine Domäne in den Suffixsuchlisten auf beiden DCs eingetragen?

Das ist dein Fehler: "Der Zielprinzipalname ist falsch"

 

Ernsthaft: du hast mehr gemacht als nur dein IP-Konzept zu ändern. Ganz sicher. Und wenn du hier nicht weiterkommst mit dem Patchen/Flicken der existierenden Umgebung dann mach die Umgebung komplett neu. Das ist kürzer. Ernsthaft. Diese Fehler gibt es nicht in freier Wildbahn. Es gibt keine Unternehmen in denen plötzlich der Kerberos-Realm aus heiterem Himmel nicht mehr synchron mit der Domäne läuft. Es ist sinnlos sich damit zu befassen ohne die Hintergründe in ihrer Tiefe verstehen zu wollen. Beim Aufsetzen der Domäne wird da nicht einmal Hand angelegt, AD und Kerberos werden vollautomatisch verschweisst und aufeinander abgestimmt.

Kerberos und AD sind 2 Seiten einer Münze. Und das Ganze ist im Grossen und Ganzen nach ueber einem Jahrzehtn Betrieb auch so gefestigt wie eine Münze. Deine Münze ist zerbrochen. Es ist einfacher sie einzuschmelzen und neu zu giessen als zu versuchen aus der Form der Stücke die Geschichte ihres Zerbrechens zu rekonstruieren.

Link zu diesem Kommentar

 Hilft mir nicht weiter auf die Idee kann ich selber auch kommen. Ich möchte das Problem lösen.

 

Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Client

domäne (DEB.TEST) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinde

n, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.

 

Hast du bei Änderung deines IP-Konzepts die Registrierung in der Domäne deaktiviert?

Ich lese das alles nicht nochmal, ist deine Domäne in den Suffixsuchlisten auf beiden DCs eingetragen?

Das ist dein Fehler: "Der Zielprinzipalname ist falsch"

 

Ernsthaft: du hast mehr gemacht als nur dein IP-Konzept zu ändern. Ganz sicher. Und wenn du hier nicht weiterkommst mit dem Patchen/Flicken der existierenden Umgebung dann mach die Umgebung komplett neu. Das ist kürzer. Ernsthaft. Diese Fehler gibt es nicht in freier Wildbahn. Es gibt keine Unternehmen in denen plötzlich der Kerberos-Realm aus heiterem Himmel nicht mehr synchron mit der Domäne läuft. Es ist sinnlos sich damit zu befassen ohne die Hintergründe in ihrer Tiefe verstehen zu wollen. Beim Aufsetzen der Domäne wird da nicht einmal Hand angelegt, AD und Kerberos werden vollautomatisch verschweisst und aufeinander abgestimmt.

Kerberos und AD sind 2 Seiten einer Münze. Und das Ganze ist im Grossen und Ganzen nach ueber einem Jahrzehtn Betrieb auch so gefestigt wie eine Münze. Deine Münze ist zerbrochen. Es ist einfacher sie einzuschmelzen und neu zu giessen als zu versuchen aus der Form der Stücke die Geschichte ihres Zerbrechens zu rekonstruieren.

 

Wie meinst du das mit oder was soll das heissen:

"

Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (DEB.TEST) von der Client

domäne (DEB.TEST) unterscheide

"

also der vollqualifizierte Name des DC ist testsrv2.deb.test und dieser ist anpingbar und ein Client von mir heisst "nicols-pc.deb.test" auch dieser ist pingbar. Verstehe die Fehlermeldung nicht.

 

 

Ich habe nichts deaktiviert mit Registierung der Domäne. Die Suffixsuchlisten müsste auf beiden DCs stimmen: C:\Users\Administrator>ipconfig /all

 
Windows-IP-Konfiguration
 
   Hostname  . . . . . . . . . . . . : testsrv2
   Primäres DNS-Suffix . . . . . . . : deb.test
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Ja
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : deb.test
 
 
Verstehe. Ja, bekomme eventuell eh einen richtigen Server dann installiere ich wohl eh alles neu. Aber wenn ich nicht weiss wo der Fehler ist, weiss ich auch nicht was ich falsch gemacht habe. :-/. Wäre halt schon toll wenn ich das Problem lösen könnte...
Link zu diesem Kommentar

Wollte eh noch was schreiben dazu,

Was du erzaehlst, klingt, ob im Rahmen der IP-Adressänderung einer der beiden DCs seine eigene Domäne gegründet hat mit demselben Namen wie die "Original-Domäne". Einfach weil die DCs für eine Weile getrennt waren oder besser weil sie nicht mehr miteinander geredet haben.

Wenn man sowas nicht täglich troubleshooted ist das eine schiit arbeit das wieder aufzuräumen.

Was bei dir passiert ist, das Kerberos nicht mehr korrekt entschluesseln kann.

 

"Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte."

 

Kann sein das es da einen Kniff gibt (vielleicht, vielleicht aber auch nicht) aber es meldet sich niemand der einen kennt.

Und so ist es einfacher entweder den "fehlerhaften" DC (welcher von den beiden das nun auch sein mag) aus der Domäne zu schmeissen per demote und ihn dann wieder aufzunehmen oder einfach gleich alles neu zu machen.

 

Du könntest schauen ob es im DNS noch _kerberos/_ldap Einträge mit der/den falschen IPs gibt. aber schon diese Suche dauert länger als alles neuzumachen.

 

Damit bin ich aber auch raus aus der Diskussion mit meinen klugen Sprüchen, den beschriebenen Fehler hatte ich vor ca. 12 oder mehr Jahren und ich war damals genauso begeistert wie du jetzt. Bin froh es hinter mir zu haben.

bearbeitet von Jim di Griz
Link zu diesem Kommentar
  • 2 Wochen später...

Wollte eh noch was schreiben dazu,

Was du erzaehlst, klingt, ob im Rahmen der IP-Adressänderung einer der beiden DCs seine eigene Domäne gegründet hat mit demselben Namen wie die "Original-Domäne". Einfach weil die DCs für eine Weile getrennt waren oder besser weil sie nicht mehr miteinander geredet haben.

Wenn man sowas nicht täglich troubleshooted ist das eine schiit arbeit das wieder aufzuräumen.

Was bei dir passiert ist, das Kerberos nicht mehr korrekt entschluesseln kann.

 

"Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte."

 

Kann sein das es da einen Kniff gibt (vielleicht, vielleicht aber auch nicht) aber es meldet sich niemand der einen kennt.

Und so ist es einfacher entweder den "fehlerhaften" DC (welcher von den beiden das nun auch sein mag) aus der Domäne zu schmeissen per demote und ihn dann wieder aufzunehmen oder einfach gleich alles neu zu machen.

 

Du könntest schauen ob es im DNS noch _kerberos/_ldap Einträge mit der/den falschen IPs gibt. aber schon diese Suche dauert länger als alles neuzumachen.

 

Damit bin ich aber auch raus aus der Diskussion mit meinen klugen Sprüchen, den beschriebenen Fehler hatte ich vor ca. 12 oder mehr Jahren und ich war damals genauso begeistert wie du jetzt. Bin froh es hinter mir zu haben.

 

Ja ich habe mich in den letzten Wochen noch etwas intensiver mit Kerberos auseinandergesetzt verstehe nun etwas mehr was die begriffe TGT, KRBT etc. heisst. Das Thema ist auch nicht gerade einfach zu verstehen dann kommen noch diese SPNs dazu. Ich habe eben nochmals dcdiag auf beiden DCs durchlaufen lassen und dort werden viele Fehler angezeigt. Wohl doch besser, auf euch zu hören und nochmals von Anfang an zu beginnen und neu zu installieren zudem ich ja eh einen neuen Server erhalten werde.

 

Ich konnte nur ldap und kerberos "SRV Einträge" im DNS finden, jedoch sind die an einen Hostnamen geknüpft nicht nicht an eine IP-Adresse und die IPs stimmen auf beiden DCs in der forward-Zone. Die Dcs mal aus der Domäne nehmen und wieder reintun könnte helfen? Das habe ich noch nicht versucht... Könnte ich noch versuchen...

 

Melde mich dann wieder sollte beim neuen System wieder fragen oder Probleme auftauchen. Danke für die Hilfe :-)

Link zu diesem Kommentar
  • 4 Wochen später...

Ich konnte datsächlich eine falsche IP-Adresse finden im DNSund habe diese nun korrigiert. Jedoch funktioniert leider winRM immer noch nicht. Ich konnte jedoch neue erkenntnisse zum Fehler finden und zwar unter Power Shell -> Test-ComputerSecureChannel wird mir das Fehler "false" zurückegeben was soviel wie mein DC hat keine Vertrauensstellung mehr zu meinem 1. DC. Hoffe, ich kann auch dieses Problem lösen, dann müsste auch alles wieder funktionieren.


Danke nochmals für deinen Tipp!



Schönen Sonntag und lieber Grüsse

Nicolas

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...