Umi

Hallo, @lefg: Ich habe einen neuen User auf dem Server angelegt und dann am Client angemeldet. Und siehe da der EDGE funktioniert. Danach habe ich das vorhandene vermeintlich defekte Benutzerprofil mit bereits vorhandener ".v6" Endung auf dem Server umbenannt. Aus vorherigen Betriebssystem und Anmeldungen waren ".v2" und ".v5" Profile bereits vorhanden. Dann habe ich den Benutzer auf dem Client kpl. gelöscht und wieder angemeldet. EDGE konnte ich allerdings nicht finden, obwohl es auf dem PC installiert war. Ich habe "Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}" ausgeführt, um fehlende APPS zu installieren, zuvor den Benutzer als Lokalen Administrator eingetragen, da es sonst zu Fehlermeldungen bei der APP Installation kam. Danach war EDGE wieder vorhanden und ausführbar. Scheint so, als hätte das ".v6" Profil, welches vom alten Windows Build erstellt wurde, beim Update auf den neuen Build entweder Schaden genommen oder es ist nicht entsprechend geupdatet worden. Bei dem Client mit dem oben beschriebenen Spezialprogramm habe ich das Profil noch nicht neu erstellen lassen. Dazu kann ich die Tage nochmal Rückmeldung geben.

@sunny61: ok, ich habe den Schlüssel gelöscht, danach zieht er sich das Benutzerprofil vom Server, allerdings zeigt der EDGE das gleiche Verhalten, zudem musste ich feststellen, dass zum Einen die Kacheln im Startmenü nicht mehr kpl. angezeigt werden, es gibt nur die EDGE Kachel und schlimmer noch man kann die "EINSTELLUNGEN" nicht mehr aufrufen. Der Eintrag wird zwar links an der Startseite angezeigt, aber nicht ausgeführt. Ebenso z.B. "Windows Update Eunstellungen" lassen sich nicht ausführen bzw. starten nicht.

So kumulatives Update (KB4032188) unter Win 10 Pro installiert. Keine Änderung. Fehler bestehen fort. Ich habe mich dann probeweise als lokaler Admin auf einem PC angemeldet und das Servergespeicherte Benutzerprofil auf dem lokalen PC umbenannt bzw. gelöscht. Den Benutzer entfernt und den PC aus der Domäne genommen. Nach Neustart wieder der Domäne hinzugefügt und ebenso den Benutzer mit Adminrechten. Soweit ging alles durch. Beim Anmelden scheint der PC den Benutzer auf dem Server zu finden, beginnt dann aber mit dem Hinweis "Windows vorbereiten" und startet mit einem temporären Profil. Eigene Dateien und Dokumente sind leer. Greife ich jedoch auf das Netzlaufwerk zu bzw. gehe ich mit dem Explorer in das Profilverzeichnnis auf dem Server kann ich auf meine Dokumente zugreifen. Ich habe dann mehrmals neugestartet. GPRESULT, NSLOOKUP zeigen auch an das alles ohne Probleme übernommen bzw. gefunden werden kann. Danach habe ich mich wieder lokal als Admin angemeldet und das Servergespeicherte Profil wieder korrekt umbenannt bzw. hergestellt. Schon läuft die Anmeldung wieder ohne Probleme durch. Leider wird mir hier unter Updates nicht angezeigt, ob ich zu der vorherigen Windows Version zurückkehren möchte? Dies wäre nämlich der nächste Schritt um dann nochmal die Benutzeranmeldung zu prüfen. gute Ideen oder Hinweis sind herzlich Willkommen!

@Zahni: Nein. Nur der Windows 10 eigene und EMET 5.5 laufen. @Sunny61: Ich lade gerade das kumulative Update (KB4032188) herunter. Sobald es installiert ist melde ich mich nochmal.

Ja UAC ist aktiv (Regler ist auf Standard gesetzt)

Hallo, ich habe hier ein Problem mit unseren Windows 10 Pro Clients, welche in den letzten Wochen von Build 1607 auf 1703 geupdatet haben. Der Server ist ein 2012 R2, alle Clients sind Windows 10 Pro und werden mit servergespeicherten / Roamingbenutzerprofilen betrieben. Nach dem Update äußert sich der Fehler auf allen Clients wie folgt: 1.) der EDGE Browser funktioniert nicht mehr, d.h. Edge startet und versucht folgende Adresse zu öffnen "https://go.microsoft.com/fwlink/?LinkId=525773", nach ca. 1-2 Sekunden schließt EDGE. Wenn man es schafft einen neuen Tab zu öffnen dann schließt EDGE nicht mehr, aber die Internetseite wird nicht geöffnet, es passiert gar nicht ausser, dass die Anzeige mit den Punkten im Tab rotiert. 2.) in der Registry wird folgender Fehler gelistet "Bei der Aktivierung der App „Microsoft.MicrosoftEdge_8wekyb3d8bbwe!ContentProcess“ ist folgender Fehler aufgetreten: Der Remoteprozeduraufruf ist fehlgeschlagen.. Weitere Informationen finden Sie im Protokoll „Microsoft-Windows-TWinUI/Betriebsbereit“. 3.) in einem spezifischen Programm, welches auf eine Firebird Datenbank (Firebird Server läuft lokal) zu greift, erhält man den Fehler "Der Index der Liste überschreitet das Maximum (-1)." Das Programm ist anscheinend in Delphi programmiert. Das Problem mit EDGE und Roaming Profilen tauchte vorher nicht auf, scheint aber schon bei anderen Usern mit früheren Windows Builds vorzukommen. Soweit ich es nach Internetrecherche überblicken konnte gibt es hierzu Vorschläge, wie den EDGE zu deinstallieren das lokale App Verzeichnis zu löschen und den EDGE neu zu installieren. Leider hilft dies anscheinend nicht bei allen Anwendern und auch bei mir nicht. Bei lokalen Anwendern startet EDGE ohne Probleme und lädt auch die abgefragte Adresss ohne Probleme. Viele gehen davon aus, dass es mit den Roaming Profilen zu tun hat. Ich sehe dies tw. auch so. Bei einem Rechner, bei dem Problem 3.) auch eintritt, habe ich das Update von Windows rückgängig machen lassen und auf Build 1607 zurückgegangen. Nun funktionieren auf diesem Rechner das spezifische Programm und EDGE wieder einwandfrei. Demnach könnte es einen Zusammenhang zw. den Roaming Profiles und dem Build 1703 geben, da es aber bei der Umstellung zurück auf 1607 keine Probleme gab scheint das Profil in Ordnung zu sein. Frage: 1.) Ist das Problem auch anderen Anwendern bekannt bzw. hat hier jemand eine konkrete Lösung? 2.) Ist das Problem bei Microsoft bekannt und welche Empfehlung gibt es z.B. auf Build 1607 verbleiben? Weiß jemand, ob an einem Fix dafür gearbeitet wird. Grüße Umi

Hallo Martin, danke für den TIP! Problem gelöst. Korrekt bei PSSshutdown ausgeführt vom NonDomainMember habe ich IP Adressen eingesetzt. RDP nutze ich von einem Client der DomainMember ist. Ich habe deinen TIP befolgt und auf dem DC die lokale Sicherheitsrichtlinie geprüft. Dort konnte ich "alle erlauben" zunächst nicht anwählen, da einige Punkte gesperrt waren. Ich habe dann die von mir erstellte Richtlinie deaktiviert und auf dem DC GPUPDATE /FORCE ausgeführt. Danach konnte ich die gesperrten Punkte ändern. Anhand von folgendem Link https://technet.microsoft.com/en-us/library/jj852167(v=ws.10).aspx konnte ich die Standardeinstellungen bei Auswahl von "nicht definiert" in der Gruppenrichtlinie den Sicherheitseinstellungen zuordnen und habe die Sicherheitseinstellungen "manuell" auf dem DC und dem Exchange geändert. Abschließend auf DC, Exchange und Clients GPUPDATE /FORCE durchgeführt. RDP sowie PSSShutdown funktionieren nun wieder wie gehabt. Problem gelöst. Grüße!

Hallo, ich bin einer NTLM Warnung 6038 (Lsass.exe) im Log des DC und des Exchange nachgegangen. Es handelt sich um eine Warnung, dass ein Client die schwache NTLM Authentifizierung statt Kerberos benutzt hat. Hierzu habe ich eine Überwachungsrichtlinie analog zu folgendem Beitrag erstellt: http://www.mcseboard.de/topic/195670-authentifizierung-per-kerberos-erzwingen-anstatt-ntlm/ Zunächst habe ich nur überwacht, jedoch dann den folgenden Punkt testweise aktiviert: Netzwerksicherheit: Beschränken von NTLM: Eingehender NTLM-Datenverkehr – Alle Konten verweigern Damit sollte Kerberos quasi erzwungen werden. Die Anmeldung der Clients funktionierte weiterhin, d.h. die Fehlermeldung wurde nicht von einem Client verursacht, sonder kam direkt von dem Server oder einem Dienst des Servers. Dabei entstanden die 2 folgenden Probleme: 1.) Als die Richtlinie aktiviert war musste ich feststellen, dass ich per Remotedesktop nicht mehr auf Clients und DC bei denen die Richtlinie aktiviert war zugreifen konnte Vorher funktionierte es. Fehler: Authentifizierungsfehler. Die lokale Sicherheitsautorität (LSA) ist nicht erreichbar Daher habe ich den Punkt auf „nicht definiert“ zurückgesetzt, sowie die komplette Richtlinie deaktiviert. Dies half aber nicht obwohl per GPUPDATE /FORCE auf Clients und DC aktualisiert wurde. Erst als ich den Punkt auf „Alle zulassen“ gesetzt habe war ein Zugriff per Remotedesktop wieder möglich. Wird der Punkt dann wieder auf "nicht definiert" gesetzt kommt es wieder zur obigen Fehlermeldung. Das würde doch heißen die Einstellung wird durch "nicht definiert" nicht auf der letzten Einstellung belassen? 2.) Zudem habe ich nun auch das Problem, dass ich alle Clients und den DC per PSSshutdown (IP Adresse) nicht mehr remote herunterfahre kann. Dabei wird das Herunterfahren vom Hyper V Host aus gesteuert, der wiederum nicht Mitglied der Domäne ist. Ich erhalte die Meldung: Couldn't access 192.xxx.xxx.xxx: access denied. Dabei ist der Punkt „Alle zulassen“ bereits aktiviert. Fragen 1. Soweit mir bekannt benötigt PSShutdown NTLM Authentifizierung, die aber nun explizit zugelassen ist oder nicht? 2. Wenn ich die Richtlinie, welche ich separat neben der default domain policy und DC default angelegt habe deaktiviere bzw. lösche und GPUPDATE ausführe bin ich davon ausgegangen, dass der Ursprungszustand wiederhergestellt wird. Es scheint aber, dass durch das einmalige aktivieren von „Alle Konten verweigern“ weitere (NTLM) Einstellungen geändert wurden, die immer noch zu einer Blockierung einzelner Teile des Systems führen. Bzw. ist ein Cache zu löschen? Oder liege ich falsch? 3. Wie lässt sich der Ursprungszustand wieder herbeiführen, sodass PSSShutdown wieder funktioniert und der Remotedesktop Zugriff ohne dass eingehender NTLM Verkehr explizit zugelassen wird? Für jeden Tip bin ich dankbar! Grüße

GELÖST Hallo Martin, herzlichen Dank dafür. Ich haben den Offline Cache zurückgesetzt und der Zugriff ist wieder möglich. viele Grüße & schönes WE, Umi GELÖST

Hallo bin leider erst jetzt wieder dazugekommen mich dem Problem wieder zu widmen. Danke für eure Beiträge. @tesso Hallo tesso, mit controluser passwords2 habe ich nur eine "generische Anmeldeinformation" zur automatischen Anmeldung des Clients an den Server gefunden, welche ich testweise gelöscht habe. Dies brachte wie geschrieben keinen Erfolg. Wo sehe ich sonst eine gespeicherte Anmeldung? @daabm Hallo Martin, ein solches Problem hatte ich zunächst vermutet, allerdings ist bei den meisten dann ein kompletter Zugang zu einem ganzen Verzeichnispfad nicht zugängig oder? Bei mir ist es ein einziges Unterverzeichnis, welches nicht direkt als Name bzw. per Klick im Explorer aufgerufen werden kann. Mag sein, dass dies trotzdem ein Kerberos / SPN Problem ist. Ich habe den Process Monitor auf Client und Server ausgeführt und als Filter "Path contains l440_datenbank" angegeben. Anbei die Ausgabe (Auszug) auf dem Client: Date & Time: 04.11.2014 17:35:50 Event Class: File System Operation: CreateFile Result: ACCESS DENIED Path: \\DCSERVER\Mustername\03 Thinkpad L440_Datenbank TID: 4904 Duration: 0.0021233 Desired Access: Read Data/List Directory, Read Attributes, Synchronize Disposition: Open Options: Synchronous IO Non-Alert Attributes: n/a ShareMode: Read, Write, Delete AllocationSize: n/a Wenn ich auf dem Client das übergeordnete Verzeichnis "Mustername" angebe, dann gibt es eine Menge Einträge, die ausfälligsten sind die bereits oben stehende und die folgende: Date & Time: 04.11.2014 17:47:05 Event Class: File System Operation: CloseFile Result: SUCCESS Path: C:\Windows\CSC\v2.0.6\namespace\dcserver\Mustername\03 Thinkpad L440_Datenbank TID: 8100 Duration: 0.0000381 Hier greift der Explorer auf den Cache der Offlinedateien zu? Und hat theoretisch Zugriff? Aber beim direkten Versuch über \\DCSERVER nicht? Auf dem Server: Date & Time: 04.11.2014 17:43:31 Event Class: File System Operation: CreateFile Result: IS DIRECTORY Path: E:\Mustername\03 Thinkpad L440_Datenbank TID: 3384 Duration: 0.0000137 Desired Access: Read Attributes, Synchronize Disposition: Open Options: Synchronous IO Non-Alert, Non-Directory File Attributes: n/a ShareMode: None AllocationSize: n/a @Martin, hast du eine Idee Wie kann ich den Fehler eingrenzen kann bzw. wonach sollte ich suchen? Ich habe mich testweise als lokaler Admin angemeldet und auf das Netzlaufwerk zugegriffen. Hier werde ich logischerweise nach Domäne und Passwort für den Zugriff gefragt. Ich habe mich als "Administrator" (Domänen-Admin) angemeldet. Dasselbe Phänomen Zugriff auf alle Verzeichnisse, nur das eine besagte wird verweigert. Somit muss ich nun davon ausgehen, dass das Problem nicht am Account des Clients liegt, sondern am Client selber. Korrekt? Ich hoffe auf weitere Tipps, viele Grüße, Umi

Hallo testperson, du meintest wahrscheinlich die Anmeldeinformationsverwaltung auf dem Client und nicht auf dem Server? Hier war auf dem Client nur eine generische Anmeldeinformation für die Domäne eingetragen. Löschen brachte keinen Erfolg. Ich habe das Passwort des Clients zurückgesetzt, aber auch kein Erfolg die Situation ist dieselbe. Irgendwo muss dann doch der Server oder Client sich vermerkt haben, dass der Zugriff auf dieses eine Verzeichnis nur per IP Adresse und nicht per Hostname funktioniert. Bzw. ein Sperrvermerk vom System eingetragen worden sein aus welchen Gründen auch immer (Absturz, nicht korrekt heruntergefahren, etc.). Nur wo ist der Eintrag? Grüße Umi

Hallo, ich habe festgestellt, dass der Zugriff vom Client über die IP Adresse auf das Verzeichnis funktioniert (\\IP\übergeordnetes Verzeichnis\03 Thinkpad L440_Datenbank) Allerdings ist über den Hostnamen anscheinend kein Zugriff auf das Verzeichnis möglich. Wie gesagt es betrifft nur das Verzeichnis mit diesem Namen, andere Verzeichnisse sind problemlos erreichbar. Grüße,Umi

Hallo Forumsmitglieder, ich habe ein Zugriffsproblem auf einen "Freigegeben Ordner" auf einem Server 2012 R2. Hintergrund: Backup eines Ordners von einem Win 7 64Bit Client (Benutzer in Domäne, lokaler Admin, Domänenbenutzer Mitglied) per robocopy auf eine Serverfreigabe Der Ordnername auf dem Server lautet "03 Thinkpad L440_Datenbank" und befindet sich in einem freigegebenen Verzeichnis mit mehreren anderen Verzeichnissen. Das Übergeordnete Verzeichnis ist als Netzlaufwerk S:\Mustername\ am dem Client angebunden. Nun habe ich die Tage festgestellt, dass das Backup nicht läuft, da der Zugriff auf das Verzeichnis verweigert wird. Ich habe die Freigabe- und Sicherheits-Einstellungen des Verzeichnisses auf dem Server kontrolliert, diese sind oder scheinen in Ordnung. Der Zugriff auf das übergeordnete Verzeichnis und andere Unterverzeichnisse läuft ohne Probleme. Nur das Verzeichnis "03 Thinkpad L440_Datenbank" wird mit der Fehlermeldung "Der Pfad ist nicht verfügbar. Auf.. kann nicht zugegriffen werden. Zugriff verweigert." quittiert. Daraufhin habe ich diverses probiert. z.B. am Client neuen Ordner (z.B. Test) auf dem Netzlaufwerk erstellt (ok) z.B. am Client "03 Thinkpad L440_Datenbank" Ordner umbennen (Zugriff verweigert) z.B. am Server "03 Thinkpad L440_Datenbank" kopiert und umbenannt in "03 Thinkpad L440_Datenbank_1" (Client Zugriff ok) z.B. am Server "03 Thinkpad L440_Datenbank" gelöscht und komplett neunen Ordner mit diesem Namen erstellt ((Client Zugriff verweigert) z.B. Server und Client Neustart selbes Verhalten z.B. per Unlocker am Client "03 Thinkpad L440_Datenbank" umbennen / löschen versucht (Zugriff verweigert) D.h. egal was ich mache der Ordnername "03 Thinkpad L440_Datenbank" scheint nicht mehr zugreifbar vom Client. Nun weiß ich nicht mehr weiter. Habe ich etwas übersehen? viele Grüße

Der Host hat 16GB, aufgeteilt in dyn. Speicher 512MB bis 6GB für den DC und fixe 8GB für den Exchange Server, somit hat der Host im schlimmsten Fall 2GB zur Verfügung. Wie gesagt dient er als Ersatz für den SBS2003 mit ca. 3-5 Clients gleichzeitig, also sollte es für DC und Exchange eher anspruchslos sein.

Hallo, wir betreiben einen SBS 2003, welcher nun allerdings ausgemustert wird. Da auf dem SBS 2003 unter anderem auch Sharepoint lief, wollte ich Sharepoint (Foundation 2013 mit SP1 deutsch) auch auf unserem neuen Windows Server Std. 2012 zum Laufen bringen. Wir haben 2 VM's auf einem HyperV Host. VM1 ist DC und auf VM2 ist Exchange 2013 installiert. Da Sharepoint auf einem DC offiziell nicht unterstütz wird, habe ich "versucht" es auf dem Exchange Server zu installieren und zwar in der Standalone Version mit SQL Express Server. Dies ist laut meiner Recherche vielleicht nicht empfehlenswert, aber es sollte technisch möglich sein. Die Installation der "prerequisites" läuft manchmal schon holprig. Mal wird die IIS Webserverrolle nicht korrekt installiert bzw. bleibt hängen mal bleibt die Installation beim SQL Server Express hängen. Dies lässt sich durch "Installation abbrechen" bzw. "Installation Task beenden" der besagten Teile und nochmaligen Aufruf bzw. Installation der "prerequisites" bereinigen. D.h. irgendwann ist es geschafft. Danach kann Sharepoint Foundation 2013 mit SP1 (de) installiert werden. Die Installation läuft ohne Fehler durch. Danach ist Sharepoint nutzbar. Leider etwas langsam, was aber dem Speicherhunger von Exchange und Sharepoint geschuldet sein könnte. DAS PROBLEM: Nach der Installation funktioniert Exchange nicht mehr (Kein OWA Zugriff / Exchange Management Shell kann sich nicht mehr am Server anmelden) Nun habe ich bei msxfaq gelesen, dass bei einer Sharepoint Installation auf einem Exchange 2003 womöglich OWA nicht mehr funktioniert. Aber bei mir funktioniert der ganze Exchange Server nicht mehr? Ich habe daraufhin nochmal die VM zurückgesetzt und nur die "prerequisites" installiert. Und schon danach funktioniert Exchange nicht mehr. Hat hier jemand bereits Erfahrungen bzw. Kenntnisse mit Sharepoint Foundation 2013 auf einem Exchange Server gesammelt. Mir ist klar, dass dies keine zu empfehlende Konfiguration ist. Allerdings würde ich gerne wissen, ob dies dennoch realisierbar ist. Vielleicht weiß jemand Rat. viele Grüße, Umi