Jump to content

jeremy

Members
  • Gesamte Inhalte

    22
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Fortschritt von jeremy

Contributor

Contributor (5/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

10

Reputation in der Community

1

Beste Lösungen

  1. jeremy

    Upgrade auf Win10

    @Dr. Melzer: Danke für's verschieben. Hab den ersten Post schon gesucht.
  2. Hallo, das Upgrade von Windows 7 Pro (OEM) mit den Media Creation Tool funktioniert problemlos, auch mit Rechnern in der Domäne Windows 10 ist nach dem Neustart ohne weiteres Zutun aktiviert. Meine Frage: Ist dies legal, d.h. würde es einer Lizenzprüfung standhalten? Gefühlsmäßig würde ich sagen Ja. Schließlich wurde der Windows7-Productkey von einem Microsoft Aktivierungsserver gegen Windows 10 bestätigt. Letztendlich passiert beim Update mit den Accessibility Tools auch nichts anderes. Und die Lizenz bleibt ja auch gültig, selbst wenn der Anwender die Tools später nicht mehr benötigt. Eine Quelle, die belegt, dass es so ist oder auch nicht, wäre hilfreich. Vielleicht hat jemand einen Link. jeremy
  3. Hallo, das Upgrade von Windows 7 Pro (OEM) nach Windows 10 Pro funktioniert mit dem Media Creation Tool problemlos. Windows 10 ist nach dem Neustart auch sofort aktiviert. Die Frage ist, ist es auch legal bzw. hält es einer Lizenzprüfung stand? M.M.n. schon, sonst hätte ein Microsoft Aktivierungsserver die Aktivierung verweigert. Falls dem so ist, oder auch nicht; hat jemand eine belegbare Bestätigung dafür? Jeremy
  4. Es sind wohl alle Dienste betroffen, die gesicherte Remoteverbindungen aufbauen und deren Zertifikat hinter den 16384 Byte kommt. Je nachdem auch, wie diese CTL aufgebaut wird. Es gab im Dez 2012 ein KB931125, das versehentlich an Server verteilt wurde und auch so ein Verhalten ausgelöst hat.
  5. Ich hab die Ursache nun gefunden. Im SysLog wurde auch das Event 36885 Quelle Schannel protokolliert. Leider zeitlich getrennt vom Auftreten des Fehlers. Dieses besagt, dass die Liste der Root-Zertifikate zu lang ist und deshalb abgeschnitten wird. Server 2008 R2 hat hier eine Grenze von 16384 Byte. Scheinbar sind dann die Zertifikate die WinRM benutzt abgeschnitten worden weshalb keine Verbindung aufgebaut werden konnte. Die Auslieferung der Liste komplett unterbunden und schon hat alles wieder funktioniert. Jetzt muss ich nur noch schauen, welche Root-Zertifikate ich löschen kann. Danke an alle, für die Hilfe :-)
  6. Ich zweifle langsam, dass es am .NET liegt. Hab jetzt mal eine Reparaturinstallation von .NET 4.61 durchgeführt und nachfolgend KB3146717 nochmal installiert: Keine Änderung Danach .NET 4.6.2 und nachfolgend KB3146717 installiert: Keine Änderung Alle Installationen sind fehlerfrei durchgelaufen, ebenso der anschließende Reboot. Das CU15 kann ich auf die Schnelle nicht installieren. Allerdings glaube ich auch nicht, dass das dann die Probleme beseitigt. Mglw. liegt es an WinRM, schließlich entsteht der Fehler bei New-PSSession. Im Windows-Remote-Management Log tauchen Fehler mit der ID 142 auf: "Fehler bei WSMan-Vorgang "CreateShell". Fehlercode: 2150858819". Hm, die Installation der CU hat bei mir bislang immer ca 3 Std. gedauert. Wir haben 5 DB mit insg. ca. 800 GB.
  7. @DocData: Die Aussicht auf DesasterRecovery macht mir gleich Mut ;-) netfx_setupverifier.exe hat schon mal keinen Fehler um .NET gefunden. Dass es den Server 2008 R2 als Windows 7 erkennt ist, denke auch, aufgrund der selben OS-Basis nicht so tragisch. [02/05/17,13:12:46] Beginning of new SetupVerifier error logging session [02/05/17,13:12:46] Build created on October 26, 2016 [02/05/17,13:12:46] For more information about repairing the .NET Framework, see http://support.microsoft.com/kb/2698555 and http://go.microsoft.com/fwlink/?LinkID=246062 [02/05/17,13:12:46] Activity log file location: C:\Users\<USER\AppData\Local\Temp\setupverifier_main_02-05-17_13.12.46.txt [02/05/17,13:12:46] Error log file location: C:\Users\<USER>\AppData\Local\Temp\setupverifier_errors_02-05-17_13.12.46.txt [02/05/17,13:12:46] Windows build version from registry: 7601.23572.amd64fre.win7sp1_ldr.161011-0600 [02/05/17,13:12:46] Detected operating system: Windows 7 (x64) [02/05/17,13:12:46] Windows directory: C:\Windows [02/05/17,13:12:46] System directory: C:\Windows\system32 [02/05/17,13:12:46] Program Files directory: C:\Program Files (x86) [02/05/17,13:12:46] Common Files directory: C:\Program Files (x86)\Common Files [02/05/17,13:13:46] ****ERROR**** Process 'change user /execute' exited with return code 1 [02/05/17,13:13:46] SetupVerifier exiting with return value 0
  8. Die Anleitung von Jeff Guillet kannte ich schon. Bei "...Exchange will need to recompile all of its .NET assemblies...." habe ich durchaus Bedenken. Vor allem wenn dies ausgehend von einem "defekten" System geschieht und man bei Exchange nicht mit Snapshots arbeiten sollte. Bei sowas fällt mir immer Alan Shepard ein: "Dear Lord, please don't let me f**k up." ;-) Könnte eine Reparatur, wie in Update#2 von Jeffs Anleitung für .NET 4.5.2 empfohlen, nicht auch bei mir helfen? Sollte ja eigentlich nur die Installation wiederholen und demzufolge zumindest nicht mehr beschädigen als schon ist. Das CU15 würde ich in diesem Zustand eher nicht installieren wollen.
  9. Zunächst mal Danke für die Antworten. Nun, es gibt tatsächlich keine dokumentierte Änderungen in letzter Zeit, abgesehen von Änderungen am Exchange selbst (Postfächer, Verteiler, Transport etc.) und natürlich Windows-Updates. Die letzten relevanten Änderungen wurden von mir im Oktober 2016 durchgeführt; die Installation von CU14 und .NET 4.6.1. Auf dem Server ist schon seit längerem WMF 4 installiert. Es hat auch alles bis zu jenem Neustart funktioniert. Die Dienste WWW-Publishingdienst und Windows-Remoteverwaltung laufen. In der Firewall sind eingehend aktiviert: Windows-Remoteverwaltung 5985 und WWW-Dienste 80. Danke für den Link, Norbert. Es funktioniert leider kein einziger WinRM-Befehl mehr. Ebensowenig Enable-PSRemoting. Ebenfalls seit dem Neustart wird im AppLog Event 1309 protokolliert und zwar jedesmal wenn die EMS gestartet wird. Hier würde ich auch die Ursache vermuten. Ich selbst hatte das Vergnügen noch nicht, hab aber schon gehört dass es Erstrebenswerteres gibt als ein defektes .NET :-( Protokollname: Application Quelle: ASP.NET 4.0.30319.0 Datum: 02.02.2017 09:52:13 Ereignis-ID: 1309 Ereigniscode: 3005 Ereignismeldung: Es ist eine unbehandelte Ausnahme aufgetreten. Ausnahmetyp: NullReferenceException Ausnahmemeldung: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. Anforderungs-URL: https://mail.<DOMÄNE>.de:443/owa/auth/logon.aspx?url=https://mail.<DOMÄNE>.de/owa/PowerShell-LiveID&reason=0 Anforderungspfad: /owa/auth/logon.aspx
  10. Hallo, seit kurzem habe ich das Problem, dass die EMS auf dem Exchange nicht mehr funktioniert. EAC, OWA, AES etc. funktionieren einwandfrei. Beim Aufruf der EMS kommt: AUSFÜHRLICH: Verbindung mit <server>.<domäne>.<tld> wird hergestellt. New-PSSession : [<server>.<domäne>.<tld>] Beim Verbinden mit dem Remoteserver "<server>.<domäne>.<tld>" ist folgender Fehler aufgetreten: [ClientAccessServer=<server>,BackEndServer=<server>.<domäne>.<tld>,RequestId=04615f29 -968a-42bf-9033-3c2b7dc4eaac,TimeStamp=03.02.2017 15:40:50] [FailureCategory=Cafe-SecureChannelFailure] Weitere Informationen finden Sie im Hilfethema "about_Remote_Troubleshooting". In Zeile:1 Zeichen:1 + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin gTransportException + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed Das Problem besteht seit einem Reboot. Im EvtLog konnte ich keine relevante Einträge finden. Die Einstellungen der virtuellen Verzeichnisse habe ich überprüft, auch hier keine Auffälligkeiten. Es sind alle Funktionen betroffen die eine RemoteShell verwenden. WinRM QuickConfig bzw. ALLE WinRM-Befehle bringen: C:>winrm quickconfig Der WinRM-Dienst wird auf diesem Computer bereits ausgeführt. WSManFault Message = Der WinRM-Client hat eine Anforderung an den Remote-WS-Verwaltungsdienst gesendet und eine Antwort erhalten, in der gemeldet wurde, dass die angeforderte HTTP-URL nicht verfügbar ist. Diese Meldung wird normalerweise von einem HTTP-Server zurückgegeben, der das WS-Verwaltungsprotokoll nicht unterstützt. Fehlernummer: -2144108269 0x80338113 Der WinRM-Client hat eine Anforderung an den Remote-WS-Verwaltungsdienst gesendet und eine Antwort erhalten, in der gemeldet wurde, dass die angeforderte HTTP-URL nicht verfügbar ist. Diese Meldung wird normalerweise von einem HTTP-Server zurückgegeben, der das WS-Verwaltungsprotokoll nicht unterstützt. C:> Momentan fehlt mir der Ansatz wo ich noch suchen könnte. Ich bin für jeden Tipp dankbar :-) jeremy
  11. Hallo, seit einigen Tagen beendet die Sicherung des Systemstatus bei einzelnen Servern mit Fehler. Wir sichern 6 Server mit BackupExec 11D, darunter 2 Windows 2000 Server mit MetaFrame XP. Letzten Donnerstag endete die Sicherung bei einem mit dem Fehler "Sichern- \\Server.Domäne.loc\System?State Element \\Server.Domäne.loc\System?State\Registry\software konnte nicht gelesen werden - übersprungen." Ein Neustart half, am Freitag hatte jedoch der andere TS die selbe Fehlermeldung. Die Tipps in der Fehlerbeschreibung V-79-57344-33916 helfen nicht, weil der Indexdienst bereits deaktiviert war und genügend Speicherplatz vorhanden ist. Eine Testsicherung des Systemstatus des betroffenen Rechners mit Ntbackup bringt eine ähnliche Meldung, dass Registrierung\System und Userdiff ncith gelesen werden kann. Die Rechte hab ich überprüft, daran leigt es nicht. Hat jemand Ideen woran es liegen könnte bzw. wie man das Problem lösen kann? Gruß, Jeremy
  12. Danke für den Tipp, Martin. Man muss die entspr. ID auf suppressed stellen. Ich hatte das zwar irgendwo in dem Cisco-Configuration Wälzer schon mal gelesen, war mir aber total entfallen. Das Alter schlägt erbarmungslos zu :D Ich hab die 402103 ausgeblendet, jetzt ist Ruhe im Karton. Allerdings wär mir eine Lösung, die den Fehler behebt schon lieber gewesen. Danke für die Unterstützung! jeremy
  13. Hi, die Erklärung von Cisco kannte ich schon. Trotzdem Danke! Es ist nur so, dass allein dieser Logeintrag ca. 50 MB Logfile/Monat erzeugt und das Loglevel auf Errors hochsetzen möchte ich eigentlich auch nicht. Im Netz habe ich praktisch nichts über dieses Problem gefunden und ich bin sicher nicht der einzige der einen Tunnel mit einer Netscreen betreibt. Darum hatte ich eigentlich eher an einen Konfigurationsfehler gedacht, irgendeine Lapalie; Komma statt Punkt gesetzt o.ä. Gruß jeremy
  14. Hallo, nach der Konfig eines Site2Site-Tunnels zwischen einer PIX501(6.3(5)) und einer Netscreen schreibt das Syslog der PIX Warnungen: "%PIX-4-402103: identity doesn't match negotiated identity (ip) dest_addr= <PIX Outside>, src_addr= <NS Outside>, prot= icmp, (ident) local=<PIX Outside>, remote=<NS Outside>, local proxy=<Host PIX-Side>/255.255.255.255/0/0, remote_proxy=<Host NS-Side>/255.255.255.255/0/0" Das Ereignis wird pünktlich alle 10s protokolliert. Der Tunnel an sich funktioniert einwandfrei, wird sicher aufgebaut und ist stabil. Ich bin die Konfig mit dem Netscreen-Admin schon mehrfach durchgegangen; wir haben keine Abweichungen gefunden. Woran könnte das liegen und vor allem, wie kann man das abstellen? Ist das eine Inkompatibilität zwischen PIX und NS oder haben wir etwas übersehen? TIA jeremy
  15. Ich hab die deutsche 70-270 am 25. August gemacht. Zu Vorbereitung hab ich benutzt: + das grüne von MS Press + Föckler/Borell + Videos von CBT Nuggets Hab mich nicht extrem vorbereitet. Die Videos geguckt, die Bücher als Bettlektüre (wirklich wahr!!!) Bestimmte Dinge; Bereiche wo ich wenig Erfahrung habe (bspw. RIS), habe ich auch ausprobiert. Ergebnis: 866 Punkte/90Min Mein Resume: Alle 3 waren sehr hilfreich, jedes auf seine Art. Das grüne ist staubtrocken aber sehr umfassend. Föckler/Borell erklärt sehr verständlich, lockert auf CBT Nuggets erklärt auch sehr gut und anschaulich ~~~~~~~~~~ Als nächstes steht die 70-290 an. Ich denke ich werds wieder mit den dreien machen.
×
×
  • Neu erstellen...