schwiz

Ok, ist gut...

Moin,

 

meine Güte, einen Mangel an Sturheit kann man dir nicht anlasten.

 

"Geändert" wurde weder bei "Windows.old" noch beim "Bootvorgang" etwas. Wie nun schon mehrfach dargelegt, ist "Windows.old" ein einfaches Ordnerbackup - genauer: ein umbenannter Ordner. Da es in diversen Konfigurationen eines lauffähigen Systems Verweise auf den Systemordner gibt, werden diese natürlich nicht mehr funktionieren, wenn der Ordner plötzlich anders heißt. Ebenso würde es keine funktionsfähige Registry geben, versuchte man, das Windows aus "Windows.old" zu starten. Muss es auch nicht, denn - falls das bislang noch nicht erwähnt wurde - es handelt sich dabei ja auch nicht um ein lauffähiges Betriebssystem.

 

Der Bootloader wird beim Upgrade (was technisch eine Neuinstallation ist) schlicht ausgetauscht. Er startet Windows 10, nicht Windows 7. Und ja, der Bootloader könnte auch Windows 7 starten, wenn es sich um ein Dual-Boot-System handelte. Vielleicht ist auch dies bislang unerwähnt geblieben, aber nach einem Upgrade hat man kein Dual-Boot-System.

 

Gruß, Nils

Mh, jedes Windows hat doch seine eigene Registery...

Moin,

 

gut, aber nur weil ich auch was von dem Popcorn will:

 

Windows.old ist kein bootfähiges Betriebssystem. Es handelt sich um ein Ordnerbackup der Dateien, die beim Upgrade ausgetauscht wurden. Das ist nur deshalb da, damit man das Upgrade rückgängig machen kann. Man kann die dort liegenden Betriebssystem-Fragmente nicht booten. Selbst wenn man das durch viel Gebastel hinbekäme, ist es nie so gedacht gewesen, und es wird mit größter Sicherheit kein stabil laufendes System dabei entstehen.

 

Wenn du ein Dual-Boot-System willst, dann musst du eins ausdrücklich installieren. Durch den Upgrade-Vorgang entsteht kein Dual-Boot-System.

 

Schön, dass du dich jetzt nebenbei über den Windows-Bootvorgang informiert hast. Das nützt dir für dein Vorhaben aber nicht.

 

Gruß, Nils

PS. Ist ja Sommerloch, da gibt es auch schon mal Wiederholungen.

Zum Bootvorgang, ja das war meine 2. Frage die ich mir nun selber beantwortet habe.

Was wurde den bei "Windows.old" geändert, sodass man davon nicht mehr gebootet werden kann? Was wurde im Bootvorgang beim Upgrade auf Win 10 geändert, sodass nun von Win 10 und nicht mehr von Win 7 gebootet wird?

Habe mich nochmals schlau gemacht und bin fündig geworden:

BIOS startet den Bootloader des MBR dieser listet alle Partitionen aus die als aktiv markiert sind auf. Anschliessend lädt wird von z.B C:\ der Bootsektor geladen im Bootsektor wird nach dem Windows Boadloader gesucht, der Bootloader làdt dann die winload.exe das System durchläuft die Runlevels.

Du wirst den Windows.old Ordner _nicht_ booten können. Genau das versuche ich dir gerade zu vermitteln.

Ok verstehe nicht wieso? Aus welchen technischen Gründen sollte das nicht möglich sein?

Kann man nicht mit BCDEdit den Pfad zur Windows Installation anpassen?

Aber das ist die Installation und kein Bootloader.

Aber in der Installation selber unter C:\Windows\Boot befinden sich sämtliche Dateien fürs Booten, u. A die "bcd-Datei" und auch der Bootloader selber zu finden unter ->  C:\Windows\Boot\PCAT\bootmgr...

Also wieso meinst du es gäbe keinen in den Installationen selber? Auf dem Sektor 1 der HDD ist doch der Verweis auf den Bootloader? Das ist bei MBR bei GPT ist das ja etwas einfacher beim Bootvorgang aber auch so kompliziert.

Ja wieso nicht? Ich geh mal davon aus. :) Ich würd aber auf die Idee auch nicht kommen, es zu versuchen. Und nein, wenn ich dir die weiteren Fragen beantworten könnte, hätte ich es getan.

Ich möchte gerne wissen wo ich das ändern kann... Ich weiss auch nicht, ob ich mit einem Tool wie den EasyBCD das ändern kann?

Windows.old beinhaltet die alten Windows Dateien bei einem Windows UPgrade (bspw. von Windows 7 auf 10 oder von 10-1511 auf 10-1607). Die kansnt du aber nicht "booten". Normalerweise kann man die aber mit der Datenträgerbereinigung löschen lassen (passiert afaik irgendwann automatisch).

Ja, wieso sollte das nicht möglich sein? Dort existiert unter Windows.old\Boot Verzeichnis??! Wo wurde die änderung gemacht das nicht mehr von Win 7 gebootet wird sondern von Win 10?

Kannst du mir die weiteren Fragen zum Bootvorgang noch beantworten?

Guten Tag

Seitdem Windows 10 upgrade habe ich einen "Windows.old" Ordner. Das heisst doch ich habe auch 2 Bootloader oder? Also müsste ich doch relativ einfach das ändern können sodass von Windows 7 d. H "Windows.old" Verzeichnis gebootet wird oder nicht?

Nun wie war das nochmals wie ist der Bootvorgang bei einem PC der mit MBR funktioniert? Wie ändere ich das um? Wo ist definiert, dass vom Windows Verzeichnis gebootet wird, nicht vom Windows.old (Windows 7)?

Wenn ich mich richtig erinnere sucht das BIOS auf allen Datenträgern nach einer "bootsek.bat" danach wird nach einer aktiven Partition gesucht und dort anschliessend nach einem Bootloader und von dort ist dann ein Verweis auf eine "winload.exe" oder wie ging das nochmals?

Ein Multiboot geht ja klar nicht da ja eben beide Windows-Versionen auf einer Partitions liegen. Jedoch wurde ja irgendwie der Bootload nachdem Upgrade auf Win10 so umkonfiguriert das auf Win 10 gebootet wird und nicht mehr von Win 7. Wo wurde das Umgestellt?

Freundliche Grüsse

Nicolas

Wenn und wie setzt man den mit "setspn" SPNs? Man muss ja zuerst einmal wissen welcher Protokoll das Programm verwendet also z. B wsman für winRM. Dann welcher Pfad verwendet werden muss. Müssen somit auf allen DCs ein SPN für winRM konfiguriert werden oder nur dort wo halt winRM installiert ist? Man kann ja SPN auch so setzten SERVICE/HOST.Domäne.TLD/Domäne.TLD... Wie geht man da vor?

Jemand der mir da weiterhelfen kann? Danke.

Für WinRM braucht man keinen SPN setzen, das macht Powershell / WinRM beim Konfigurieren automatisch.

Unter Umständen nutzt WinRM bzw. Powershell Remoting "http/".

Hatte damit schon Probleme, dass dies durch eine Webapplikation blockiert wurde.

Wenn und wie setzt man den mit "setspn" SPNs? Man muss ja zuerst einmal wissen welcher Protokoll das Programm verwendet also z. B wsman für winRM. Dann welcher Pfad verwendet werden muss. Müssen somit auf allen DCs ein SPN für winRM konfiguriert werden oder nur dort wo halt winRM installiert ist? Man kann ja SPN auch so setzten SERVICE/HOST.Domäne.TLD/Domäne.TLD... Wie geht man da vor?

Kerberos kennst Dü? http://technet.microsoft.com/library/cc772815.aspx

Namen sind alles - und das Protokoll dazu. HOST ist ein generischer Eintrag für jeden COmputeraccount. Und alles und jeder, der per Kerberos-Auth auf etwas zugreifen will, benötigt ein Service-Ticket für diesen Zugriff, daher die vielen Namen und Protokolle. DNS ist drin wegen der "sicheren dynamischen Updates", dafür muß sich der Client ja beim DNS authentifizieren. Oder so ähnlich

Aha ok. Wie setzte ich den z. B einen SPN für winRM? Wie geht man da vor? Man kann ja entweder im ADSI Editor direkt eintragen oder per Shell -> set SPN...

Guten Tag

Ich habe mich in den letzten Tagen und Wochen schlau gemacht über Kerberos. Nun habe ich noch Fragen zu SPN. Hier mal ein Screenshot zu welchen ich Fragen habe:

1.) Was sind das für ein Dienst dieser "HOST"/.... welcher Kerberos benötigt?

2.) Bei ldap sind nach dem Hostname und dem Domäne noch Werte /DP607101.... siehe Bild

Wozu dienen diese Einträge z. B "ForestDnsZone.dp607101.local". Heisst dass, wenn ich bei Windows Server unter DNS schaue all die Einträge von Kerberos benutzt werden können um Authentifizierungen durchzuführen?

Die Einträge mit /DomainDnsZone und ForestDNSZone verstehe ich ist ja unter DNS ja gut ersichtlich was damit gemeint ist aber wozu werden die gelb Markierten Einträge verwendet:

ldap/Hostname.Domäne.Tld/Domäne

(DP607101 ist der Name der Domäne.)

Gruss

Nicolas

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

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 :-)

Ich verweise nochmal auf: http://www.mcseboard.de/topic/206401-winrm-funktioniert-nicht-mehr/?p=1296719

 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

Kann mir bitte jemand weiterhelfen? Das Problem besteht leider nachwievor. :(

 

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

Einfach nix zu machen... Hoffe, ihr könnt mir sagen wie ich diesen Dienst, wenn es dieser ist reparieren kann Google half nicht weiter.

dann hat sich der Fehler im Vergleich zum ersten Post aber verändert.

Nicht funktionierende KDCs sind eine vollkommen andere Baustelle als die WinRM-Config.

Wenn es eh nur 2 DCs in einer virtuellen Testumgebung sind, installier diese neu. Dann wird der KDC und damit der WinRM funktionieren. Beide Services gehören eher zu den Unkomplizierten ihrer Art.

Also die Info stammt aus dem Ereignisprotokoll. Die Meldung im ersten Post steht weiterhin in den Aufgabendetails. 

Okay... Also ist nicht winRM sondern vielmehr Kerberos das Problem? Wie kann ich diesen KDC-Dienst neu installieren? Wie kann ich diesen Dienst wieder zum Laufen bringen? Ich habe aus eigenen Erfahrungen mit SFC bereits andere Dienste die nicht mehr funktionierten damit reparieren können. Leider beim KDC-Dienst ohne Erfolg. Also nicht beide DCs sind virtuelle nur einer davon. Alles neu installieren würde ich echt ungerne tun, nur weil winRM nicht mehr geht. 

Also dieser "KDC Proxyserver"- Dienst ist dafür das Kerberos richtig funktioniert und der sollte immer laufen? Weshalb ist der Starttyp auf manuell gesetzt? Im Ereignisprotokoll steht auch nix davon, dass der Dienst versucht wurde zu starten.

//Edit: In der Fehlermeldung steht, dass Key Distrubution Center ein Problem hat. Welcher Dienst ist das den nun? Ich habe den Kerberos-Schlüsselverteilungscenter Dienst der läuft und der KDC-Proxyserverdienst (KPS) der eben nicht läuft. Verstehe nicht was dieser KDC-Dienst mit Proxy zu tun haben soll.

dann hast du testsrv2 richtig konfiguriert und WinRM funktioniert.

Warum der testsrv3 nicht an den testsrv2 hinkommt, findest du am besten mit einem Netzwerksniffer wie wireshark.org heraus. Unter dieser Seite gibt es reichlich sehr lohnenswerte Anleitungen für alle Level, falls du dich in dem Gebiet noch nicht so auskennst!

Gut zu hören.

Aber es muss doch irgendwo an winRM liegen, was soll mir Wireshark da weiterhelfen. Im Log steht der Fehler wenn mir jemand sagen könnte, wie ich das Problem lösen könnte.

Hier der Fehler:

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv2$" empfangen. Der verwendete Zielname war DEB\TESTSRV2$. Dies deutet 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 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 Zieldienstkonto nicht mit dem Kennwort übereinstimmt, das im Kerberos-KDC (Key Distribution 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 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 vollqualifizierten Namen, um den Server zu identifizieren.

Der Fehler ist doch eindeutig. Was muss ich tun? Wie kann ich das Problem ändern? Ich habe versucht den Kerberos-Ticket-Cache zu löschen mit -> "klist ?" jedoch ohne Erfolg. Den Dienst "KDC" kann ich nicht starten als Fehler erhalte ich "Fehler 5: Zugriff verweigert". Jemand eine Idee wie ich den Dienst reparieren kann? Übrigens habe ich auf beiden DCs diese Nacht SFC durchlaufen lassen jedoch auch wieder ohne Erfolg :-(

Der Dienst "KDC" scheint wohl so wie ich das erkenne, das Problem zu sein indem er sich nicht starten lässt. Auf beiden DCs! Wieso auch immer...

Hoffe, dass euch diese neuen Erkenntnisse weiterhelfen.

Schönen Abend

Warum deaktiviert man IPv6?

 

Das OS benutzt das? Und nur den Haken in der Netzwerkkarte raus heißt nicht, das es deaktiviert ist.

Bereinige erst einmal die IPv4 Settings, dann sieht man ggf. weiter.

 

Und wie du an den Tips von blub gesehen hast, ist das OS unten drunter auch englisch - also solltest du dich wohl oder über mal zeitnah damit beschäftigen, sonst wird das leider nichts, auch nicht, wenn du es aus Hobby-Gründen wissen möchtest.

 

In der Ausbildung hatten wir IPv6 auch deaktiviert da wir das nicht benutzt hatten...

Gut, das OS kann auch ohne IPv6 auskommen?

Du meinst wohl die IPv6 bereinigen statt IPv4? Also soll ich mal IP46 wieder aktivieren? winRM ging vorher auch, obwohl IPv6 deaktiviert war. 

Eine Sprache perfekt beherrschen, sodass man alles versteht auch solche komplizierten IT-Themen ist nicht in ein paar Tagen gelernt ;-) Zudem ich jetzt schon 2 Sprache spreche :-) 

$computername = "testsrv3"  #testsrv3 ist dein Rechnername

enter-PsSession $computername

Sorry, aber verstehe nicht was du mir genau sagen willst...

Ich soll auf dem Host "testsrv2" enter-PsSession testsrv2 eingeben, dass klappt ja.  Hingegen enter-PsSession testsrv3 geht auf dem "testsrv2" nicht.

Woher kommt die 169er APIPA IPv4 Adresse?

 

Wie viele Netzwerkkarten sind drin, wie viele sind am Switch und wie konfiguriert?

 

Warum hat der so viele IPv6 Adressen?

 

Keine Ahnung woher diese APIPA-Adressen kommen. Eventuell hatte ich mal etwas falsch konfguriert und darum steht dort noch diese Adresse. ipconfig /all zeigt mir nirgends eine solche Adresse. Das Netzwerk läuft sonst gut! Ich komme mit beiden DCs ins Internet.

Habe nur eine NIC. Meinst du den virtuellen Switch von HyperV?

Screenshot vom Server aufdem der HyperV läuft:

Screenshot vom virtuellen Server

Wieso so viele IPv6-Adressen drin sind kann ich dir nicht sagen. Auf beiden DCs habe ich in den Netzwerkeinstellungen IPv6 deaktiviert da ich es nicht benutzte. 

Dann sollte es serverseitig doch funktionieren.

Kannst du auf dem Server selbst eine Connection auf sich selbst öffnen?

 

Powershell:

Enter-PsSession $computername

 

In der Registry kannst du die Listener auch manuell bearbeiten bzw. löschen

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Listener\

(sofern du nicht mit GPOs arbeitest)

 

ansonsten bitte mal in der Powershell

"get-help about_remote"

ansehen. Am Ende gibt es Verweise auf weitere Hilfen wie "get-help about_Remote_Requirements", in der du sicher wertvolle Tipps finden wirst.

 

blub

Also habe ich ausgeführt (Enter-PsSession testsrv2 (ohne Dollar-Zeichen gehts nur)):

PS C:\Users\Administrator> Enter-PsSession $testsrv2
Enter-PSSession : Das Argument für den Parameter "Session" kann nicht überprüft werden. Das Argument ist NULL oder
leer. Geben Sie ein Argument an, das nicht NULL oder leer ist, und führen Sie den Befehl erneut aus.
In Zeile:1 Zeichen:17
+ Enter-PsSession $testsrv2
+                 ~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Enter-PSSession], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.EnterPSSessionCommand

PS C:\Users\Administrator> Enter-PsSession testsrv2
[testsrv2]: PS C:\Users\Administrator\Documents> Enter-PsSession testsrv2

Was machte die Funktion? Wenn ich "Enter-PsSession testsrv3" eingebe kommt eine Fehlermeldung der Server ist der Remote-Server.

Der Listener stimmt ja soweit?!

Das Powershell cmdlet 

Set-WSManQuickConfig

konfiguriert dir ohne weitere Paramter serverseitig den winrm

see:  https://technet.microsoft.com/de-de/library/hh849867.aspx

 

und mit

winrm enumerate winrm/config/listener

kannst du anschließend nachsehen, ob es geklappt hat. So sollte das Resultat etwa aussehen

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.91.221, 169.254.105.146, 169.254.144.53, 169.254.173.18, 192.168.178.27, ::1, 2001:0:5ef5:79f....

Beide Befehle im Adminkontext am Server ausführen

 

blub

winrm enumerate winrm/config/listener vorher:

Das stimmt doch so alles oder? Listing on 192.168.0.2 ist der Management-Server.

Nachdem ausführen von "Set-WSManQuickConfig":

Leider klappts immer noch nicht :-( Habe sogar im Server-Manager den Remote-Server entfernt und neu hinzugefügt und gleich wieder der Kerberos Fehler  :nene:  :confused:

Kann man winRM nicht irgendwie löschen? Als ich winRM installiert habe musste ich auch noch .NET und winRM Management Framework installieren. Da .NET noch von anderen Diensten abhängig ist kann ich das ja nicht alles nur weil winRM nicht geht deinstallieren... Was ratet ihr mir an? Ein Update von wimRM auf die neue WinRM Management Framework ist auch Fehlgeschlagen irgend ein Zertifikatfehler.

Das Update für WinRM Management konnte ich auch nicht finden... Auch die zugehörige KB-Nummer steht nirgends.

Habe winRM nach dieser Anleitung konfiguriert: http://blog.alekel.de/server-2008-und-2008-r2-mit-dem-server-manager-201-verwalten/

Habe nochmals etwas herumprobiert hier noch mehr Infos zum Fehler:

Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "testsrv3$" empfangen. Der verwendete Zielname war DNS/testsrv3.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 (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 Server 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, 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 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 vollqualifizierten Namen, um den Server zu identifizieren.

Du darfst in Zukunft auf den Thread im Technet hinweisen: http://social.Technet.microsoft.com/Forums/de-DE/windowsserver8de/thread/31ae6096-b4fe-4c63-84bd-6af2bfe71ca1#31ae6096-b4fe-4c63-84bd-6af2bfe71ca1

 Da ich hier wenig Erfolg hatte muss man halt doppelsspurig fahren.

sonst noch jemand eine Idee was ich tun könnte um das Problem zu lösen?