jeremy

@Dr. Melzer: Danke für's verschieben. Hab den ersten Post schon gesucht.

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

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

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.

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

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.

@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

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.

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

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

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

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

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

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

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.

@Operator Ich hab die Frage so verstanden, dass die Sichtbarkeit nur Informationschrakter für den User hat. Anyway, ich dachte halt Information kann man auch schön verpacken ;)

Anders gefragt, muss es eine DOS-Box sein? Du könntest ein VBS ablaufen lassen, ohne dass der User etwas davon sieht. Nachdem es durchgelaufen ist lässt du ein Popup öffnen mit den Ergebnissen. Sieht schöner aus und das Popup kann man selbstschließend machen. Das Script ist in dieser Form nicht getestet!!! ############################ Option Explicit On Error Resume Next Dim WSHNetwork, WSHShell, CRLF, objArgs, strMsg, strCompany, i, colDrives Dim colPrinters, strUserName, strLogonSRV, strPrintSRV, strFileSRV, strDomain Dim nReturnCode, nSecondsToWait CRLF = Chr(13) & Chr(10) strLogonSRV = "DC" strPrintSRV = "Printserver" strFileSRV = "FileSErver" Set WSHNetwork = Wscript.CreateObject("WScript.Network") Set WSHShell = WScript.CreateObject("WScript.Shell") Set objArgs = Wscript.Arguments ' ---------------------------------------------------------- ' Synchronisieren der Zeit mit dem Domänenkontoller nReturnCode = wshShell.Run("net time \\" & strLogonSRV & " /set /yes", 0, TRUE) If (nReturnCode <> 0) Then MsgBox "Es war nicht möglich die lokale Uhrzeit zu synchronisieren." & vbNewLine &_ "Bitte melden Sie sich beim System-Administrator.",48,"Logon Script Fehler" Else strMsg = "Zeitsynchronisation mit """ & strLogonSRV & """ erfolgreich" & CRLF & CRLF End If ' ---------------------------------------------------------- ' Einrichten der Netzlaufwerke strCompany = "Firma" strDomain = WSHNetwork.UserstrDomain strUserName = "" On Error Resume Next Do While strUserName = "" strUserName = WSHNetwork.strUserName loop WSHNetwork.RemoveNetworkDrive "H:" WSHNetwork.MapNetworkDrive "H:", "\\" & strFileSRV & "\home\" & strUserName WSHNetwork.RemovePrinterConnection "Drucker" WSHNetwork.AddWindowsPrinterConnection "\\" & strPrintSRV & "\Drucker" Set colDrives = WSHNetwork.EnumNetworkDrives Set colPrinters = WSHNetwork.EnumPrinterConnections ' ---------------------------------------------------------- ' Überschrift strMsg = strMsg & CRLF & "Anmelde Ergebnisse" & CRLF & CRLF & _ "Benutzername" & Chr(9) & "= " & strUserName & CRLF & "Computername" & Chr(9) & "= " & _ WSHNetwork.ComputerName & CRLF & "Domäne" & Chr(9) & Chr (9) & "= " & strDomain & CRLF ' ---------------------------------------------------------- ' Anzeigen der erfolgreich verbunden Laufwerke If colDrives.Count = 0 Then strMsg = strMsg & CRLF & "Kein Netzlaufwerk ist verbunden." & CRLF Else strMsg = strMsg & CRLF & "Verbundene Netzlaufwerk(e):" & CRLF For i = 0 To colDrives.Count - 1 Step 2 strMsg = strMsg & CRLF & colDrives(i) & Chr(9) & colDrives(i + 1) Next End If ' ---------------------------------------------------------- ' Anzeigen der erfolgreich verbundenen Drucker If colPrinters.Count = 0 Then strMsg = strMsg & CRLF & CRLF & "Kein Netzwerk-Drucker ist verbunden." & CRLF Else strMsg = strMsg & CRLF & CRLF & "Verbundene Netzwerk-Drucker:" & CRLF For i = 0 To colPrinters.Count - 1 Step 2 strMsg = strMsg & CRLF & colPrinters(i) & Chr(9) & colPrinters(i + 1) Next End If Function zeit zeit = "Systemzeit: " & Chr(9) & FormatDateTime(Date, 1) & " - " & FormatDateTime(Time, 4) End Function WshShell.PopUp zeit & CRLF & CRLF & strMsg,10," " & strUserName & "@" & strCompany,64 Set WSHNetwork = Nothing Set WSHShell = Nothing Set objArgs = Nothing Set colDrives = Nothing Set colPrinters = Nothing ############################

Der SBS mag günstiger sein, allerdings sind die CALs teuerer. Davon abgesehen ist der SBS auf 75 User begrenzt, darüberhinaus muss das TransitionPack gekauft werden. http://www.microsoft.com/germany/ms/sbserver/2003/lizenzierung/index.htm Bei der Useranzahl wären schon mal aus Verfügbarkeitsgründen 2 DC angebracht. Da hätte außerdem den Vorteil, die Dienste schön aufteilen zu können. Wenn allerdings alle Daten inkl. der Profile gesichert werden sollen brauchst du auch eine entspr. leistungsfähige Backuplösung. Das Limit von 4.000,- € dürfte zu diesem Zeitpunkt bereits überschritten sein.

Ist es wirklich von den Maschinen abhängig oder melden sich bestimmte User eben nur an diesen Maschinen an? Kann man ja einfach testen. Wenn das zutrifft solltest du mal die effektiven Rechte überprüfen, evtl. hast du irgendwo in der Hierarchie ein 'Verweigern' drin.

Wenn der alte Server ein DC ist, bring doch den neuen als weiteren DC in die Domäne. Eigentlich sollten sich die beiden unmittelbar nach dem hochstufen replizieren. Bevor du den alten DC abschaltest musst du noch die Rollen und den GC übertragen http://support.microsoft.com/default.aspx?scid=kb;de;255504

Also der Bildchen-Dialog geht in der Domäne definitiv nicht und das ist auch gut so. Stell dir vor du hast 1.000 User. Dann viel Spaß beim Bildersuchen. Außerdem ist dann ja auch die Benutzerumschaltung aktiviert. Ob das in einer Domäne so angebracht ist??

Mach doch mal in der Kommandozeile ipconfig -all > ipconfig.txt und poste den Inhalt hier.