8
Kein Zugriff auf Netzlaufwerk möglich - Konto deaktiviert
Hallo zusammen,
aktuell absolviere ich eine Ausbildung zum Fachinformatiker. Anfang der Woche sind wir von der Firma aus zu einem Kunden gefahren, der ein ganz besonderes Problem hat und bisher haben wir keine Lösung dafür gefunden. Mit „wir“ sind drei Azubis gemeint. Wir sollen das Problem in Zusammenarbeiten lösen, kommen jedoch nicht weiter.
Die Ausgangsituation ist folgende:
Betriebssystem Windows 7. Eine Benutzerin kann auf eines der insgesamt 7 Netzlaufwerke nicht mehr zugreifen. Es handelt sich um eine Buffalo Linkstation. Beim Start des Rechners kann er schon nicht mehr die Netzlaufwerkverbindung herstellen und meldet einen Fehler.
„Es konnten nicht alle Netzlaufwerke wiederhergestellt werden.“
Auf die anderen 6 Netzlaufwerke kann wie immer zugegriffen werden.
In der Netzwerkumgebung taucht die Linkstation zwar auf, aber wenn sie angewählt wird erscheint folgender Fehler:
„Auf \\Netzlaufwerk kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, die Netzwerkressource zu verwenden. Anmeldung fehlgeschlagen. Das Konto ist zurzeit deaktiviert.“
Weder in der Active Directory, noch in der WebKonsole der Linkstation ist das Benutzerkonto deaktiviert. Alles sieht völlig normal aus und es funktionierte vorher einige Jahre. Gleiches Benutzerkonto auf einem anderen Rechner und es geht. Anderer Benutzer am Problemrechner und es funktioniert ebenfalls. Nur die Kombination Rechner und erwähntes Benutzerkonto funktioniert nicht. Nachdem wir die Netzwerkkarte komplett deinstalliert hatten und den Rechner neu starteten, war zunächst alles langsamer, aber wir konnten wieder auf das Laufwerk zugreifen. Das lag wohl daran, dass der Netzwerkkarte die automatische IP Vergabe zugeteilt wurde. Als wir die alten Daten wieder eingetragen hatten, ging es wieder nicht. Eine andere IP hat aber ebenfalls nicht den gewünschten Erfolg gebracht. So langsam sind wir echt am Verzweifeln. Was genau kann hier passiert sein und wie bekommen wir das wieder repariert? Für jeden Tipp wäre ich euch dankbar.
lg-Buddy
aktuell absolviere ich eine Ausbildung zum Fachinformatiker. Anfang der Woche sind wir von der Firma aus zu einem Kunden gefahren, der ein ganz besonderes Problem hat und bisher haben wir keine Lösung dafür gefunden. Mit „wir“ sind drei Azubis gemeint. Wir sollen das Problem in Zusammenarbeiten lösen, kommen jedoch nicht weiter.
Die Ausgangsituation ist folgende:
Betriebssystem Windows 7. Eine Benutzerin kann auf eines der insgesamt 7 Netzlaufwerke nicht mehr zugreifen. Es handelt sich um eine Buffalo Linkstation. Beim Start des Rechners kann er schon nicht mehr die Netzlaufwerkverbindung herstellen und meldet einen Fehler.
„Es konnten nicht alle Netzlaufwerke wiederhergestellt werden.“
Auf die anderen 6 Netzlaufwerke kann wie immer zugegriffen werden.
In der Netzwerkumgebung taucht die Linkstation zwar auf, aber wenn sie angewählt wird erscheint folgender Fehler:
„Auf \\Netzlaufwerk kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, die Netzwerkressource zu verwenden. Anmeldung fehlgeschlagen. Das Konto ist zurzeit deaktiviert.“
Weder in der Active Directory, noch in der WebKonsole der Linkstation ist das Benutzerkonto deaktiviert. Alles sieht völlig normal aus und es funktionierte vorher einige Jahre. Gleiches Benutzerkonto auf einem anderen Rechner und es geht. Anderer Benutzer am Problemrechner und es funktioniert ebenfalls. Nur die Kombination Rechner und erwähntes Benutzerkonto funktioniert nicht. Nachdem wir die Netzwerkkarte komplett deinstalliert hatten und den Rechner neu starteten, war zunächst alles langsamer, aber wir konnten wieder auf das Laufwerk zugreifen. Das lag wohl daran, dass der Netzwerkkarte die automatische IP Vergabe zugeteilt wurde. Als wir die alten Daten wieder eingetragen hatten, ging es wieder nicht. Eine andere IP hat aber ebenfalls nicht den gewünschten Erfolg gebracht. So langsam sind wir echt am Verzweifeln. Was genau kann hier passiert sein und wie bekommen wir das wieder repariert? Für jeden Tipp wäre ich euch dankbar.
lg-Buddy
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 356032
Url: https://administrator.de/forum/kein-zugriff-auf-netzlaufwerk-moeglich-konto-deaktiviert-356032.html
Ausgedruckt am: 21.04.2025 um 21:04 Uhr
8 Kommentare
Neuester Kommentar
Moin,
Manchmal liegen solche Probleme nicht am Client, sondern am Server, hier das NAS...
Habt ihr die LinkStation schon mal neugestartet?
Und ist die LS ins AD integriert, sodass man die Shares mit einem AD-Konto verbinden kann oder sind hierfür dedizierte User nötig?
Gruß
em-pie
P.S. Macht euch mal nach dem AEG-Prinzip schlau;)
Das klappt meistens
Manchmal liegen solche Probleme nicht am Client, sondern am Server, hier das NAS...
Habt ihr die LinkStation schon mal neugestartet?
Und ist die LS ins AD integriert, sodass man die Shares mit einem AD-Konto verbinden kann oder sind hierfür dedizierte User nötig?
Gruß
em-pie
P.S. Macht euch mal nach dem AEG-Prinzip schlau;)
Das klappt meistens
Hi,
diese Aussage
Erste Aussage
Wenn ein anderes Benutzerkonto an diesem Computer problemlos auf die Buffalo zugreifen kann, warum zum Geier habt Ihr dann angefangen, am Netzwerk zu schrauben? Welche Schlussfolgerungen habt Ihr da getroffen?
Dieser andere Benutzer ist auch ein AD-Konto? Oder ein lokales?
Zweite Aussage:
Habt Ihr auch die Gegenprobe gemacht? Also mit anfänglicher DHCP-Adresse ging es. Mit zwei verschiedenen statischen Adressen nicht. Habt Ihr danach noch einmal mit einer DHCP-Adresse versucht? Nur mit dieser Erkenntnis nützt diese Aussage etwas.
E.
diese Aussage
Gleiches Benutzerkonto auf einem anderen Rechner und es geht. Anderer Benutzer am Problemrechner und es funktioniert ebenfalls.
und dieseDas lag wohl daran, dass der Netzwerkkarte die automatische IP Vergabe zugeteilt wurde. Als wir die alten Daten wieder eingetragen hatten, ging es wieder nicht. Eine andere IP hat aber ebenfalls nicht den gewünschten Erfolg gebracht.
sind zwei verschiedene Problemfelder.Erste Aussage
Wenn ein anderes Benutzerkonto an diesem Computer problemlos auf die Buffalo zugreifen kann, warum zum Geier habt Ihr dann angefangen, am Netzwerk zu schrauben? Welche Schlussfolgerungen habt Ihr da getroffen?
Dieser andere Benutzer ist auch ein AD-Konto? Oder ein lokales?
Zweite Aussage:
Habt Ihr auch die Gegenprobe gemacht? Also mit anfänglicher DHCP-Adresse ging es. Mit zwei verschiedenen statischen Adressen nicht. Habt Ihr danach noch einmal mit einer DHCP-Adresse versucht? Nur mit dieser Erkenntnis nützt diese Aussage etwas.
E.
Danke für eure Bemerkungen. Als Azubis machen wir sicher noch nicht alles richtig und jeder Hinweis, auch Kritik kann uns weiterhelfen. Gerne möchte ich eure Fragen beantworten.
Wir haben zuerst die Linkstation neu gestartet. Der Fehler blieb allerdings. Die LS ist nicht in der AD eingetragen. Der Zugriff erfolgt über eingetragene User in der WebKonsole der LS.
Der bzw. die anderen User, die wir zum testen auf dem Rechner angemeldet haben, waren alle AD Konten, die ebenfalls in der Linkstation als Zugriffsberechtigt eingetragen sind. Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen. Den Problemrechner weist er dagegen sofort ab.
Die Netzwerkkarte haben wir deinstalliert und wieder neu installiert, weil kein vorheriger Weg zum Erfolg führte. Ganz logisch war das natürlich nicht, aber der Fehler ist es unserer Meinung nach auch nicht. Das Ganze dauert nur wenige Minuten und so haben wir den Versuch gestartet. Als es dann per DHCP funktionierte und danach mit fester IP nicht mehr, haben wir das nochmal mit DHCP probiert und da ging es wieder. So konnten wir das Ganze allerdings nicht belassen.
Wir haben zuerst die Linkstation neu gestartet. Der Fehler blieb allerdings. Die LS ist nicht in der AD eingetragen. Der Zugriff erfolgt über eingetragene User in der WebKonsole der LS.
Der bzw. die anderen User, die wir zum testen auf dem Rechner angemeldet haben, waren alle AD Konten, die ebenfalls in der Linkstation als Zugriffsberechtigt eingetragen sind. Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen. Den Problemrechner weist er dagegen sofort ab.
Die Netzwerkkarte haben wir deinstalliert und wieder neu installiert, weil kein vorheriger Weg zum Erfolg führte. Ganz logisch war das natürlich nicht, aber der Fehler ist es unserer Meinung nach auch nicht. Das Ganze dauert nur wenige Minuten und so haben wir den Versuch gestartet. Als es dann per DHCP funktionierte und danach mit fester IP nicht mehr, haben wir das nochmal mit DHCP probiert und da ging es wieder. So konnten wir das Ganze allerdings nicht belassen.
Zitat von @Buddy98:
Danke für eure Bemerkungen. Als Azubis machen wir sicher noch nicht alles richtig und jeder Hinweis, auch Kritik kann uns weiterhelfen. Gerne möchte ich eure Fragen beantworten.
Ist ja auch nicht dramatisch. Man macht ja eine Ausbildung, um Grundlagen zu erlernen und Erfahrungen zu sammeln. Wobei letzteres ein kontinuirlicher Prozess is Danke für eure Bemerkungen. Als Azubis machen wir sicher noch nicht alles richtig und jeder Hinweis, auch Kritik kann uns weiterhelfen. Gerne möchte ich eure Fragen beantworten.
Wir haben zuerst die Linkstation neu gestartet.
OK.Der Fehler blieb allerdings. Die LS ist nicht in der AD eingetragen. Der Zugriff erfolgt über eingetragene User in der WebKonsole der LS.
Warum macht ihr das? Der einfachkeit halber würde ich die LS ins AD aufnehmen und dann könnt ihr die Zugriffe via GPO/ Gruppenzuordnungen steuern. Das ist wesentlich handlicher. So läuft es bei uns seit Jahren, mit der NAS.Der bzw. die anderen User, die wir zum testen auf dem Rechner angemeldet haben, waren alle AD Konten, die ebenfalls in der Linkstation als Zugriffsberechtigt eingetragen sind. Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen. Den Problemrechner weist er dagegen sofort ab.
Hmm...Die Netzwerkkarte haben wir deinstalliert und wieder neu installiert, weil kein vorheriger Weg zum Erfolg führte. Ganz logisch war das natürlich nicht, aber der Fehler ist es unserer Meinung nach auch nicht. Das Ganze dauert nur wenige Minuten und so haben wir den Versuch gestartet. Als es dann per DHCP funktionierte und danach mit fester IP nicht mehr, haben wir das nochmal mit DHCP probiert und da ging es wieder. So konnten wir das Ganze allerdings nicht belassen.
Habt ihr ma eine völlig andere feste IP verwendet oder immer die selbe?Andere Frage noch: liegen die Clients und das NAS im selben Subnetz? Wenn Nein, blockt da ggf. eine Firewall (Windows-interne oder Hardware-Applinace) irgendwas?
Und: Habt ihr die LS mal mit einer aktuellen Firmware ausgestattet?
Hallo Buddy98,
emeriks Aufteilung in zwei Problemfelder ist durchaus logisch.
Deine bisherigen Fehlerbeschreibungen sind in Bezug auf diese Aufteilung allerdings verwirrend.
Ich wüsste jetzt nicht in welchen Problemfeld ich zuerst suchen würde.
Vielleicht ist es auch eine unerwartete Verknüpfung der Problemfelder?
Ich nenne die fragliche Benutzerin mal Frau Müller.
Stand der Dinge:
Nur folgende Kombination schlägt fehl:
Frau Müller an ihrem Rechner mit fester IP.
Im Folgenden ein paar Dinge, die ich Euch zum Ausprobieren vorschlagen möchte.
Ich habe sie nummeriert, damit Du hier leicht darauf bezugnehmen kannst.
Die Nummerierung stellt keine Priorisierung dar.
Welche Punkte Ihr, in welcher Reihenfolge ausprobiert, sei Euch überlassen.
Es böte sich an, die, die am einfachsten anwendbar sind, zuerst auszuprobieren.
Dokumentiert bei allen, was Ihr ausprobiert, genau, was Ihr macht und welche Wirkung es hat.
Notizen, Screenshots, Fotos oder was auch immer geeignet sein sollte.
Macht immer nur eine Änderung, einen Test nach dem anderen, nie zwei auf einmal.
1. IP-Einstellungen
1.1 Vergleicht alle IP-Einstellungen von Frau Müllers Rechner mit denen eines funktionierenden Rechner.
1.2 Prüft ob Frau Müllers Rechner mehrere Netzwerkkarten hat.
Falls ja, dann deaktiviert alle, bis auf die eine, die benutzt werden soll.
1.3 Tauscht die feste IP von Frau Müllers Rechner mit einem anderen Rechner und prüft, ob das Problem mitwandert.
Vorher gilt es mit dem Admin zu klären, ob bei dem temporären Test ein lokaler DNS umkonfiguriert werden muss oder ob was auch immer beachtet werden muss.
1.4 Lasst Frau Müllers Rechner eine IP per DHCP beziehen.
Wenn es dann wieder funktioniert, dann nutzt genau diese IP mit allen zugehörigen IP-Einstellungen temporär als feste IP.
1.5 Baut eine andere Netzwerkkarte ein und gebt dieser die feste Problem-IP.
Die jetzige Netzwerkkarte ist vermutlich onboard, also deaktivieren, ansonsten ausbauen.
2. Buffalo
2.1 Vergleicht mal Punkt für Punkt alle Einstellungen zu Frau Müller mit anderen Benutzerkonten, die gleiche Rechte haben sollten.
Benutzerkonten, Freigabe-Zugriffrechte, was auch immer
Löscht Frau Müllers Benutzer-Eintrag aus der Buffalo.
Kommte sie dann auch bis zur Passwortabfrage?
Legt das Benutzerkonto wieder neu an.
2.3 Gibt es in der Buffalo irgendwelche Blacklisten?
Falls ja, dann kontrollieren.
3. Anderes
3.1 Versucht an Frau Müllers Rechner, als Frau Müller angemeldet eine Freigabe der Buffallo per Eingabeaufforderung zu mounten.
Versucht das mit einem anderen, gültigen Benutzernamen und mit Frau Müller.
3.2 Startet Frau Müllers Rechner in der jetzigen Problemkonfigurationen, aber zieht zuvor das Netzwerkkabel ab.
Wartet nach dem Start wenigsten fünf Minuten und stöpselt dann das Netzwerkkabel ein.
3.3 Schaltet bei Frau Müllers Rechner temporär den Virenschutz ab.
3.4 An Frau Müllers Rechner alle automatischen Verbindungen/Verbindungsversuche zur Buffalo trennen/deaktivieren.
Zugeordnete Laufwerksbuchstaben, Logon-Skripte, Autostartsachen (Autostart-Ordner, Reg-Einträge, Aufgabenplanung, Gruppenrichlinen
3.5 Vergleicht Frau Müllers Rechner mit anderen Rechnern, in Bezug auf installierte Software, insbesondere auf Antivieren/Antimalware-Paket, Addblocker, sogenannte Optimierungstools und alle anderen.
3.6 Nutzt Eure Zeit lieber besser und geht für 5 Euro/Std. irgendwo Putzen und kauft Frau Müller vom verdienten Geld einen neuen Rechner.
Das bringt Euch eventuell schneller zum Ziel.
Gruß Frank
emeriks Aufteilung in zwei Problemfelder ist durchaus logisch.
Deine bisherigen Fehlerbeschreibungen sind in Bezug auf diese Aufteilung allerdings verwirrend.
Ich wüsste jetzt nicht in welchen Problemfeld ich zuerst suchen würde.
Vielleicht ist es auch eine unerwartete Verknüpfung der Problemfelder?
Ich nenne die fragliche Benutzerin mal Frau Müller.
Stand der Dinge:
- Jeder darf von jeden Rechner aus (auch von Frau Müllers)
- Frau Müller darf von jedem Rechner aus, nur nicht von ihrem.
- Hat Frau Müllers Rechner allerdings eine DHCP-IP, so darf sie auch von ihren Rechner aus.
Nur folgende Kombination schlägt fehl:
Frau Müller an ihrem Rechner mit fester IP.
Im Folgenden ein paar Dinge, die ich Euch zum Ausprobieren vorschlagen möchte.
Ich habe sie nummeriert, damit Du hier leicht darauf bezugnehmen kannst.
Die Nummerierung stellt keine Priorisierung dar.
Welche Punkte Ihr, in welcher Reihenfolge ausprobiert, sei Euch überlassen.
Es böte sich an, die, die am einfachsten anwendbar sind, zuerst auszuprobieren.
Dokumentiert bei allen, was Ihr ausprobiert, genau, was Ihr macht und welche Wirkung es hat.
Notizen, Screenshots, Fotos oder was auch immer geeignet sein sollte.
Macht immer nur eine Änderung, einen Test nach dem anderen, nie zwei auf einmal.
1. IP-Einstellungen
1.1 Vergleicht alle IP-Einstellungen von Frau Müllers Rechner mit denen eines funktionierenden Rechner.
ipconfig /all1.2 Prüft ob Frau Müllers Rechner mehrere Netzwerkkarten hat.
Falls ja, dann deaktiviert alle, bis auf die eine, die benutzt werden soll.
1.3 Tauscht die feste IP von Frau Müllers Rechner mit einem anderen Rechner und prüft, ob das Problem mitwandert.
Vorher gilt es mit dem Admin zu klären, ob bei dem temporären Test ein lokaler DNS umkonfiguriert werden muss oder ob was auch immer beachtet werden muss.
1.4 Lasst Frau Müllers Rechner eine IP per DHCP beziehen.
Wenn es dann wieder funktioniert, dann nutzt genau diese IP mit allen zugehörigen IP-Einstellungen temporär als feste IP.
ipconfig /all zum Vergleich vorher/nacher heranziehen, um zu sehen, dass die Einstellungen identisch sind, bis auf dhcp/statisch.1.5 Baut eine andere Netzwerkkarte ein und gebt dieser die feste Problem-IP.
Die jetzige Netzwerkkarte ist vermutlich onboard, also deaktivieren, ansonsten ausbauen.
2. Buffalo
Zitat von @Buddy98:
Der Zugriff erfolgt über eingetragene User in der WebKonsole der LS.
...
Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen.
Die Buffalo kenne ich nicht und damit auch nicht deren Webinterface.Der Zugriff erfolgt über eingetragene User in der WebKonsole der LS.
...
Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen.
2.1 Vergleicht mal Punkt für Punkt alle Einstellungen zu Frau Müller mit anderen Benutzerkonten, die gleiche Rechte haben sollten.
Benutzerkonten, Freigabe-Zugriffrechte, was auch immer
Zitat von @Buddy98:
Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen.
2.2 In Absprache mit dem Admin der Buffalo:Selbst andere, nicht in der LS eingetragene Benutzer sind zumindest bis zur Passwortabfrage gekommen.
Löscht Frau Müllers Benutzer-Eintrag aus der Buffalo.
Kommte sie dann auch bis zur Passwortabfrage?
Legt das Benutzerkonto wieder neu an.
2.3 Gibt es in der Buffalo irgendwelche Blacklisten?
Falls ja, dann kontrollieren.
3. Anderes
3.1 Versucht an Frau Müllers Rechner, als Frau Müller angemeldet eine Freigabe der Buffallo per Eingabeaufforderung zu mounten.
Versucht das mit einem anderen, gültigen Benutzernamen und mit Frau Müller.
net use X: \\buffalo\Freigabe /user:HerrMeiernet use X: /delete (zum Trennen, falls erfolgreich verbunden)net use X: \\buffalo\Freigabe /user:FrauMueller3.2 Startet Frau Müllers Rechner in der jetzigen Problemkonfigurationen, aber zieht zuvor das Netzwerkkabel ab.
Wartet nach dem Start wenigsten fünf Minuten und stöpselt dann das Netzwerkkabel ein.
3.3 Schaltet bei Frau Müllers Rechner temporär den Virenschutz ab.
3.4 An Frau Müllers Rechner alle automatischen Verbindungen/Verbindungsversuche zur Buffalo trennen/deaktivieren.
Zugeordnete Laufwerksbuchstaben, Logon-Skripte, Autostartsachen (Autostart-Ordner, Reg-Einträge, Aufgabenplanung, Gruppenrichlinen
3.5 Vergleicht Frau Müllers Rechner mit anderen Rechnern, in Bezug auf installierte Software, insbesondere auf Antivieren/Antimalware-Paket, Addblocker, sogenannte Optimierungstools und alle anderen.
3.6 Nutzt Eure Zeit lieber besser und geht für 5 Euro/Std. irgendwo Putzen und kauft Frau Müller vom verdienten Geld einen neuen Rechner.
Das bringt Euch eventuell schneller zum Ziel.
Gruß Frank
Vielen Dank für eure bisherigen Beiträge. Wir werden einiges davon sicher durchgehen und umsetzen. Ich melde mich danach noch einmal und berichte.
Gruß-Buddy
Gruß-Buddy
So wie versprochen hier nun die Lösung, welche wir umgesetzt haben. Anhand der Kommentare ist es uns gelungen, eine strukturiertere Arbeitsweise anzuwenden und so kamen wir Schritt für Schritt vorwärts. Dafür nochmal ein großes Dankeschön!
Zuerst haben wir die IP und den DNS Server automatisch zuweisen lassen. Mittels ipconfig /all haben wir dann alle relevanten Einstellungen ausgelesen Danach konnten wir auf das Netzlaufwerk wieder zugreifen, allerdings waren die Erstzugriffe im Netzwerk sehr langsam. Uns ist zudem noch aufgefallen, dass als DNS Server ein sonst nicht dafür verwendeter Router automatisch zugewiesen wird. Seine IP Adresse lautet #.#.#.251 Als Standard Adresse bei allen anderen Rechnern im Netzwerk ist jedoch #.#.#.240 und als sekundärer DNS Server ist #.#.#.250 eingetragen. Wir haben einige Kombinationen getestet und stellten fest, wann immer der #.#.#. 240 als erster DNS Server eingetragen war, funktionietre der Zugriff nicht mehr. Auf allen anderen Rechnern klappt das jedoch fehlerlos und eben auch schnell. Wir vermuteten, dass es am Benutzerprofil auf dem Rechner der Mitarbeiterin liegen könnte. Dort war kein unter ihrem Kürzel angelegtes Benutzerprofil vorhanden. Jetzt kommt aber erst noch das dicke Ende. Wir erfuhren nebenher, wie das Benutzerkonto damals überhaupt eingerichtet wurde.
Bevor die Mitarbeiterin ihren Dienst bei der Firma angetreten hat, war eigentlich jemand anderes dafür eingeplant. Der Mitarbeiter sollte seinen Dienst antreten und den Vertrag unterschreiben, aber er ist kurzfristig wieder abgesprungen. Das AD Benutzerkonto wurde für ihn jedoch schon eingerichtet und auch an seinem Arbeitsplatz wurde schon alles vorbereitet. Anstatt jedoch den AD Benutzer zu löschen und eine neue Benutzerin anzulegen, wurde das Benutzerprofil nur umbenannt und das wohl im laufenden Prozess. Das heißt, die Mitarbeiterin war bereits unter den Daten des abgesprungenen Mitarbeiters auf dem Rechner eingeloggt. Daher fanden wir unter den angelegten Windows Benutzerkonten auch nicht ihr eigenes. Sie hat das Kürzel sb und der andere Mitarbeiter hatte das Kürzel ts. Trotzdem sie sich mit sb an der Domäne angemeldet hat, nutzte sie in Windows das Benutzerprofil ts von ihrem quasi Vorgänger. Ein Benutzerkonto sb war nicht vorhanden. Auf den anderen Rechnern hat der Zugriff auf das Netzlaufwerk unter ihrem Konto immer funktioniert. Dort wurde auch ordungsgemäß beim ersten anmelden, dass korrekte Benutzerprofil sb angelegt. Außerdem funktionierten die Netzwerkeinstellungen tadellos, also auch die eingetragenen DNS Server. Das war für uns ein entscheidener Hinweis.
Wir haben zuerst alle relevanten Daten aus dem Windows Benutzerprofil ts gesichert und dann das alte AD Benutzerkonto gelöscht und die Benutzerin dort neu angelegt. Beim ersten anmelden auf ihrem Rechner, wurde nun korrekt ein sb Benutzerprofil angelegt. Der Zugriff auf alle Netzlaufwerke war erfolgreich. Natürlich war das mit Arbeit verbunden, da viele Einstellungen wieder von Hand auf eingestellt werden mussten, aber es hat sich gelohnt und es hat uns gezeigt, wie wichtig richtige Einstellungen und Vorgehensweisen in der AD sind.
Ich hoffe, dass alles verständlich rüber gekommen ist, was bei soviel Verwirrung sicher schwieriger ist.
Gruß-Buddy
Zuerst haben wir die IP und den DNS Server automatisch zuweisen lassen. Mittels ipconfig /all haben wir dann alle relevanten Einstellungen ausgelesen Danach konnten wir auf das Netzlaufwerk wieder zugreifen, allerdings waren die Erstzugriffe im Netzwerk sehr langsam. Uns ist zudem noch aufgefallen, dass als DNS Server ein sonst nicht dafür verwendeter Router automatisch zugewiesen wird. Seine IP Adresse lautet #.#.#.251 Als Standard Adresse bei allen anderen Rechnern im Netzwerk ist jedoch #.#.#.240 und als sekundärer DNS Server ist #.#.#.250 eingetragen. Wir haben einige Kombinationen getestet und stellten fest, wann immer der #.#.#. 240 als erster DNS Server eingetragen war, funktionietre der Zugriff nicht mehr. Auf allen anderen Rechnern klappt das jedoch fehlerlos und eben auch schnell. Wir vermuteten, dass es am Benutzerprofil auf dem Rechner der Mitarbeiterin liegen könnte. Dort war kein unter ihrem Kürzel angelegtes Benutzerprofil vorhanden. Jetzt kommt aber erst noch das dicke Ende. Wir erfuhren nebenher, wie das Benutzerkonto damals überhaupt eingerichtet wurde.
Bevor die Mitarbeiterin ihren Dienst bei der Firma angetreten hat, war eigentlich jemand anderes dafür eingeplant. Der Mitarbeiter sollte seinen Dienst antreten und den Vertrag unterschreiben, aber er ist kurzfristig wieder abgesprungen. Das AD Benutzerkonto wurde für ihn jedoch schon eingerichtet und auch an seinem Arbeitsplatz wurde schon alles vorbereitet. Anstatt jedoch den AD Benutzer zu löschen und eine neue Benutzerin anzulegen, wurde das Benutzerprofil nur umbenannt und das wohl im laufenden Prozess. Das heißt, die Mitarbeiterin war bereits unter den Daten des abgesprungenen Mitarbeiters auf dem Rechner eingeloggt. Daher fanden wir unter den angelegten Windows Benutzerkonten auch nicht ihr eigenes. Sie hat das Kürzel sb und der andere Mitarbeiter hatte das Kürzel ts. Trotzdem sie sich mit sb an der Domäne angemeldet hat, nutzte sie in Windows das Benutzerprofil ts von ihrem quasi Vorgänger. Ein Benutzerkonto sb war nicht vorhanden. Auf den anderen Rechnern hat der Zugriff auf das Netzlaufwerk unter ihrem Konto immer funktioniert. Dort wurde auch ordungsgemäß beim ersten anmelden, dass korrekte Benutzerprofil sb angelegt. Außerdem funktionierten die Netzwerkeinstellungen tadellos, also auch die eingetragenen DNS Server. Das war für uns ein entscheidener Hinweis.
Wir haben zuerst alle relevanten Daten aus dem Windows Benutzerprofil ts gesichert und dann das alte AD Benutzerkonto gelöscht und die Benutzerin dort neu angelegt. Beim ersten anmelden auf ihrem Rechner, wurde nun korrekt ein sb Benutzerprofil angelegt. Der Zugriff auf alle Netzlaufwerke war erfolgreich. Natürlich war das mit Arbeit verbunden, da viele Einstellungen wieder von Hand auf eingestellt werden mussten, aber es hat sich gelohnt und es hat uns gezeigt, wie wichtig richtige Einstellungen und Vorgehensweisen in der AD sind.
Ich hoffe, dass alles verständlich rüber gekommen ist, was bei soviel Verwirrung sicher schwieriger ist.
Gruß-Buddy
@Buddy98
OK.
Die Lösung war offenbar eine Kombination aus beidem.
Aber:
Der Name des lokalen Benutzerprofilordners ("ts" statt "sb") hat nichts damit zu tun. Namen sind nur Schall und Rauch.
Das kam daher, dass Windows den Ordnernamen beim ersten Anmelden des Benutzers an einem Computer vergibt, sofern noch keine lokale Kopie eines Profils für diesen Benutzer vorhanden. Der lokale Profilordner von Petra kann also "Paula", "Pauline" oder "Pumuckel" lauten. Völlig egal, solange in der Registry korrekt zugeordnet. Die Zuordnung erfolgt über die SID des Benutzers. Dieses "Problem" mit den abweichenden Ordnernamen ist eine normale Begleiterscheinung, wenn man den Loginamen eines Benutzers ändert.
Wenn man z.B. zwei Domänen im AD hat, und in jeder z.B. einen Benutzer je mit Loginnnamen "Petra", und beide melden sich abwechselnd am selben Computer an, einmal mit DomäneA\Petra und einmal mit DomäneB\Petra, dann kann nur eine von beiden den Profilordnernamen "Petra" bekommen. Wer sich zuerst anmeldet. Das andere Konto bekommt vollkommen regulär "Petra.000".
OK.
Die Lösung war offenbar eine Kombination aus beidem.
Aber:
Der Name des lokalen Benutzerprofilordners ("ts" statt "sb") hat nichts damit zu tun. Namen sind nur Schall und Rauch.
Das kam daher, dass Windows den Ordnernamen beim ersten Anmelden des Benutzers an einem Computer vergibt, sofern noch keine lokale Kopie eines Profils für diesen Benutzer vorhanden. Der lokale Profilordner von Petra kann also "Paula", "Pauline" oder "Pumuckel" lauten. Völlig egal, solange in der Registry korrekt zugeordnet. Die Zuordnung erfolgt über die SID des Benutzers. Dieses "Problem" mit den abweichenden Ordnernamen ist eine normale Begleiterscheinung, wenn man den Loginamen eines Benutzers ändert.
Wenn man z.B. zwei Domänen im AD hat, und in jeder z.B. einen Benutzer je mit Loginnnamen "Petra", und beide melden sich abwechselnd am selben Computer an, einmal mit DomäneA\Petra und einmal mit DomäneB\Petra, dann kann nur eine von beiden den Profilordnernamen "Petra" bekommen. Wer sich zuerst anmeldet. Das andere Konto bekommt vollkommen regulär "Petra.000".
