schwiz

Ok, ist gut...

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

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.

Ok verstehe nicht wieso? Aus welchen technischen Gründen sollte das nicht möglich sein? 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.

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?

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

Jemand der mir da weiterhelfen kann? Danke.

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?

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

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

Hilft mir nicht weiter auf die Idee kann ich selber auch kommen. Ich möchte das Problem lösen. 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...

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

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.

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.

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

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

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. 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?!

winrm enumerate winrm/config/listener vorher: PS C:\Users\Administrator> winrm enumerate winrm/config/listener Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 127.0.0.1, 169.254.60.229, 192.168.0.2, ::1, fe80::5efe:169.254.60.229%14, fe80::5efe:192.168.0.2%16, fe80::ffff:ffff:fffe%13, fe80::54c6:96dc:90d8:3ce5%15 Das stimmt doch so alles oder? Listing on 192.168.0.2 ist der Management-Server. Nachdem ausführen von "Set-WSManQuickConfig": WinRM ist bereits zum Empfangen von Anforderungen auf diesem Computer konfiguriert. WinRM ist bereits für die Remoteverwaltung auf diesem Computer eingerichtet. Ausgabe von "winrm enumerate winrm/config/listener": Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 127.0.0.1, 169.254.60.229, 192.168.0.2, ::1, fe80::5efe:169.254.60.229%14, fe80::5efe:192.168.0.2%16, fe80::ffff:ffff:fffe%13, fe80::54c6:96dc:90d8:3ce5%15 Macht der Befehl "Set-WSManQuickConfig" und der cmd Befehl -> "winrm quickconfig" nicht das Gleiche? 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. 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?