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

Laut Forum und Ereignisprotokoll Text soll man registerdns auf dem Client ausführen. Also habe ich Forward und Reverse Zone des Clients auf dem Server gelöscht und registerdns auf dem Client ausgfeführt. Forward und ReverseZone wurden ordnungsgemäß eingefügt. Nur "pingen" geht immer noch nicht!

Hallo, habe ich soeben gemacht in der resetlog.txt steht dabei u.a. als letzte Einträge reset Linkage\UpperBind for PCI\VEN_8086&DEV_4227&SUBSYS_10118086&REV_02\4&20975680&0&00E1. bad value was: REG_MULTI_SZ = PSched reset Linkage\UpperBind for PCI\VEN_14E4&DEV_1601&SUBSYS_202017AA&REV_02\4&192AC53F&0&00E0. bad value was: REG_MULTI_SZ = PSched reset Linkage\UpperBind for ROOT\MS_NDISWANIP\0000. bad value was: REG_MULTI_SZ = PSched Ist das hilfreich? Auch das Programm habe ich ausprobiert, keine Besserung. Folgendes habe ich aber nach nochmaliger Durchsicht der Ereignisanzige gefunden: Die Ressourceneinträge von Host (A) für den Netzwerkadapter mit folgenden Einstellungen konnte nicht registriert werden: Adaptername : {B2DEEBAD-1951-414B-A385-A67DF1AD3325} Hostname : THINKPADZ61M Primäres Domänensuffix : UMLAUFDNS.local DNS-Serverliste : 192.168.0.100 Server, an den das Update gesendet wurde : 192.1.1.1 IP-Adressen : 192.168.0.106 ....

Hallo, nein kein weiterer Virenscanner auf der Maschine. WLAN aktiviert und deaktiviert führt zum selben Ergebnis. Soll heißen, weder an WLAN noch an LAN kann gepingt werden, wenn WLAN an ist. Ich habe nur die Einstellung mit deaktiviertem WLAN angegeben, das ist im normalen Betrieb so. Ich hatte nur die Möglichkeit in Betracht gezogen, dass vielleicht ein Ping über WLAN funktioniert, aber Fehlanzeige. Die Maschine lässt sich nicht anpingen.

Ipconfig all from Problemclient: Windows-IP-Konfiguration Hostname: THINKPADZ61M Primäres DNS Suffix: UMLAUFDNS.local Knotentyp: Broadcast IP-Routing aktiviert: Nein WINS-Proxy aktiviert: Nein DNS-Suffixsuchlsite: UMLAUFDNS.local Ethernetadapter LAN Verbdindung Verbindungsspezifisches Suffix: (hier steht nichts) Beschreibung: Broadcom NetXtreme Gigabit Ethernet Physikalische Adresse: 00-16-36-73-B2-13 DHCP aktiviert: Nein IP Adresse: 192.168.0.106 Subnetzmaske: 255.255.255.0 Standardgateway: 192.168.0.1 DNS-Server: 192.168.0.100 Windows Firewall ist auf dem Client eingeschaltet, Echoantwort per ICMP aktiviert. Ping zum Client habe ich mit THINKPADZ61M als auch als IP 192.168.0.106 durchgeführt, beides mal Zeitüberschreitung

Hallo! Ich habe heute auch ein Ping Problem bei einem unserer Clients festgestellt, was sich eher zufällig durch Installation von UltraVNC ergab und ich vom Server aus UltraVNC auf "diesem einen" Client nicht erreichen konnte. Danach folgte ein ping test...der nicht funktionierte. Szenario: SBS 2003 + 4 XP Clients / Problem bei XP SP3 Client Notebook Der Problem Client meldet sich ordnungsgemäß an und auch alle Zugriffe auf den Server (Laufwerke / Outlook) Ping an den Server ist ok. Ein Ping an diesen Client ist nicht möglich (Zeitüberschreitung). NSLookup zeigt die richtige IP (fest) und den Client Namen. Ein ping vom ProblemClient an sich selbst, an den Server und andere funktioniert auch problemlos. Reinweg der Ping an diesen Client funktioniert nicht egal ob vom Server oder anderen Clients aus. Firewall auf dem ProblemClient habe ich testweise deaktiviert, kein Erfolg. Problemclient hat WLAN und LAN. Feste Adressen. Von keinem Rechner anpingbar. Auch ein Wechsel der IP Adressen brachte keinen Erfolg. Was mich stutzig macht, alles scheint problemlos zulaufen (Server Anmeldung / Outlook usw. es gibt keine Fehlereinträge im Ereignisprotokoll). Nur der Ping funktioniert nicht und darum bekomme ich wahrscheinlich auch keine Ultra VNC remote Sitzung zustande. Server oder Client Problem? Hat da jemand einen guten Rat für mich? Vielen Dank im Voraus, mfg Umi

ok, besten Dank!

Hallo GuentherH! Was bedeutet "Ein Image Programm kann einen Exchange nicht sauber sichern." ?? So wie ich es verstehe.... a) Früher lag Exchange + System auf C: 1. vor einem Update mache ich ein Image (System + Mails gesichert) 2. Update 3. wenn alles ok ist mache ich zur Sicherheit noch ein Image, sonst setze ich das System zurück Das Ganze läuft dann ab, wenn keiner mehr den Server braucht. Es sind eh nur 3 Arbeitsstationen, also kann ich das gut managen. Wenn ich jetzt das Image ziehe, denke ich dass der gesamte Exchange korrekt gesichert ist und wenn ich es zurücksetze habe ich die Platte wie vor dem Update. Aus diesem Grunde verstehe ich deine Aussage nicht. Es ist mir klar, dass ich damit Mails und andere Daten verlieren kann, die sich z.B. bei einem Plattencrash nach x Tagen ereignen, da ich dann nur das Image habe und keine NTBckup Sicherung! Aber darum geht es mir momentan mit der Image Frage nicht! Ich würde dann zusätzlich ein NT Backup vom Exchange machen. Nur mit den Updates die eingespielt werden bin ich immer ein bisschen vorsichtig, bzw. hatte schon schlechte Erfahrungen, so dass ich das System gerne "schnell" wiede zurücksetzen kann! Wenn ich alles auf C: habe klappt das, so wie ich es mir vorstelle. Ich dachte nur auf D: den Exchange auslagern wäre die richtige Lösung. Da stimmst du mir ja auch zu! Kann ich mit meinem Updateprozedere, wie beschrieben, weitermachen, wenn der Exchange sich auf D: befindet? Sprich nur C: sichern vor einem Update, obwohl der Exchange komplett auf D: liegt? Ich vermute mal dass bei einem Update auch Updates auf dem Exchange in D: eingespielt werden und diesen würden ich dann ja nicht zurücksetzen, sondern nur Laufwerk C: Also so: a) System auf C:, Exchange auf D: 1. vor einem Update mache ich ein Image (System gesichert) 2. Update 3. wenn alles ok ist mache ich zur Sicherheit noch ein Image, sonst setze ich das System auf C: zurück, auf Laufwerk D: bleibt alles beim alten Ich hoffe, man kann mich verstehen: Wird das Programm Exchange auf Laufwerk D: so verändert, dass es bei einem Rücksetzen von Laufwerk C: Probleme gibt? Wenn ja, dann ist der Weg mit dem kompletten SBS auf Laufwerk C: die richtige Lösung für mich! Auch wenn dir wahrscheinlich dabei der Magen dreht. Ich bin kein IT Profi, sondern suche nur eine "schnelle, einfachere und sichere" Lösung mit Variante A, fahre ich eigentlich schon 2 Jahre ganz gut. Ich möchte aber wie bereits gesagt den Server neu aufsetzen (größere Platten) und hatte daher nach Vorschlägen zur Partitionsaufteilung gesucht. Nur scheint dies möglicherweise meine Backup Pläne zu kreuzen. Vielleicht kannst du mir kurz noch einen Kommentar geben, was du davon hälst ob es mit B geht, wie ich es mir vorstelle oder ob ich "für mich" besser bei Variante A bleiben soll. Vielen Dank, Gruß Stephan!

Hallo! Ich möchte unseren SBS 2003 neu aufsetzen. Dazu habe ich nun das System auf C: installiert, aber Datenintensive Dinge möchte bzw. habe ich auf D: (Datenpartition) installiert. Soll heißen ich habe hier Exchange, Client Apps, usw. installiert. Nun habe ich bei unserem alten System, die komplette SBS Installation auf C: gehabt. Zur Sicherung benutze ich Acronis True Image. Den Vorteil, den ich schätze ist, dass ich vor und nach einem Update von Windows ein Image mache und so bei auftretenden Fehlern zurücksetzen kann. Nachteilig war, dass die Mail Fächer auf den alten Stand zurückgesetzt wurden. Das soll aber kein schwerwiegendes Problem darstellen. Meine Frage: Ich habe nun die SBS Installation aufgeteilt in C: und D: wie beschrieben. Reicht es nun bei einem Update von Windows und einem möglichen Fehler C: wiederherzustellen und Laufwerk D: nicht zurückzusetzen d.h. vor allen Dingen Exchange so zu belassen?? Der Vorteil wäre die Mail Fächer hätten zu jedem Zeitpunkt den gleichen Inhalt, bei Problemen mit der Partition C:. Oder könnte dies kritisch werden beim Updaten, so dass auch Exchange updates unter D: erhält? Ich hatte beim Neuaufsetzen des Servers hier im Forum geschaut, wie man am besten die Partitionen aufteilt. Daher habe ich die Aufteilung reines System auf C: und Daten auf D: (Exchange) gewählt. Kann mir hier jemand seine Erfahrungen schildern oder einen guten Rat geben? War mein vorheriger Weg komplettes SBS auf C: die bessere Lösung? Das Imageprogramm soll auf jeden Fall verwendet werden, dies soll auch kein Problem sein bezgl. DC, da dieser der einzige Server im Netzwerk ist und bleibt! Besten Dank im Voraus und Viele Grüße, Stephan!

Hallo! Zunächst mal Danke für die Bemühungen! 1. keine Zeitunterschiede alle werden vom WINDOW SBS NTP Server mit der PTB Braunschwieg Zeit versorgt (Richtlinie) 2. Wird die Propagierung von Änderungen verhindert (Richtlinie) ? nochmal geprüft keine derartige Richtlinie wurde eingestellt "RSOP.MSC" auf dem Client betsätigt dies! 3. @megge "denke / dahcte ich auch" ABER wie bereits gesagt alle notwendigen a) Berechtigungen und Freigaben sind wie beschrieben nach meinem Kenntnisstand ausreichend b) Habe auch testweise einen Benutzer angelegt im Stammverzeichnis einer Partition also D:\TestBenutzer und die Freigaben und Berechtigungen gesetzt zusätzlich mit Berechtigung des TestBenutzer für Vollzugrif, Leider auch damit kein Erfolg =>Somit liegt es meiner Meinung nach nicht an den Berechtigungen 4. Ordnerumleitung besteht nur für Eigene Dateien auf \\Server\users\Username\Eigene Dateien, Profilumleitungen werden unter Benutzereigenschaften angegeben und befinden sich in \\Server\Profile\Username

Hallo -Zeitunterschiede? Müsste ich checken, eigentlich aber nicht alle werden vom Server mit der Uhrzeit der PTB Braunschweig versorgt und sollte somit auf allen "fast gleich" sein. -zwischengespeicherte Profile bleiben lokal gespeichert (dies ist aber soweit ich weiß auch der Normalfall und von mir erwünscht) -Wird die Propagierung von Änderungen verhindert (Richtlinie) ? gute Frage, welches wäre die entsprechende Richtlinie? Ich habe eigentlich keine Einstellungen an den Richtlinien vorgenommen, habe diese auch nochmal gecheckt in der SBS Serverkonsole werden Benutzeränderungen oder Einstellungen ja direkt angezeigt, da ich keine vorgenommen habe, greift "nicht angegeben", also Einstellung normal würde ich sagen -Was mir noch aufgefallen ist, dass die Ordnerumleitung vom Ordner Eigene Dateien korrekt funktioniert. Bei der Abmeldung und Anmeldung auch das Synchronisationsfenster erscheint und so wie es aussieht auch eine Synchronisation durchgeführt wird, da auch kein Fehler ausgegeben wird. Das Profil auf dem Server aber wird wie gesagt nicht aktualisiert.