Zugriff auf iNet Share - 1. Zugriff schlägt stets fehl

[fedcba]

Hallo,

als relativer i Series Anfänger habe ich aktuell ein Phänomen das ich mir nicht erklären kann, von dem ich mir aber nicht vorstellen kann das erfahrene Hase das nicht kennen (konnte aber über Google und in diesem Forum doch nichts dbzgl finden):

Wir haben über iNet einen Ordner im IFS freigegeben. Diesen binde ich bei den Benutzern wie gewohnt als Laufwerk mit entsprechenden Laufwerksbuchstaben (\\<ip>\<freigabe>) in Windows 10 permanent ein.

Nun ist es so das bei den Benutzern die erste Anmeldung wohl stets fehlschlägt, jedenfalls werden die Benutzer beim Starten des Rechners immer im iNet deaktiviert. Aktivere ich die Benutzer wieder, funktioniert der Zugriff auf die Freigabe ohne Probleme. Die Zugangsdaten sind also nicht per se falsch.

Ich weiß das Windows intern bei der Anmeldung an Freigaben mit expliziten Benutzerdaten den Benutzernamen ggf. in mehrere Varianten durchprobiert. Ein IBM Artikel empfahl den Benutzernamen in der Varianten in der Form <ip der i series>\<benutzername>, aber das habe ich wie auch andere Varianten ( <benutzername, <ip>\<benutzername> , <hostname>\<benutzername>, <qhostname>\<benutzername>) ausprobiert, ohne Erfolg.

Bei mir und einem Kollegen haben wir das Phänomen nicht, wir haben aber auch die Freigabe mit dem Hostnamen (\\<hostname>\<freigabe>) eingebunden, da wir anders als die Benutzer eine lokale Host Datei haben (die i Series selber ist nicht im DNS eingetragen).

Weiß hier vielleicht jemand wo das Problem besteht ? Mir geht es weniger darum das weg zu bekommen (die Benutzer nutzen die Freigabe eigentlich eh nicht), sondern würde nur gerne wissen warum das passiert.

[Fuerchau]

"Ich weiß das Windows intern bei der Anmeldung an Freigaben mit expliziten Benutzerdaten den Benutzernamen ggf. in mehrere Varianten durchprobiert."

Fehlgeschlagene Anmeldungen führen i.d.R. nach 3-5 Versuchen zur Abmeldung des Profiles (hier halt im iNet-Server). Es hätte auch das Profil auf der IBM i sein können.

Warum Windows dies so macht obwohl die Anmeldedaten doch gespeichert sind, entzieht sich mir.
Es ist auch die Frage wann Windows dies bereits durchführt.
Alternativ kann man folgende Einstellung (ggf. per GPO) vornehmen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\NetworkProvider
(falls nicht vorhanden als DWORD 32 erstellen) auf 0 setzen.
Dann wird erst beim Zugriff auf das Laufwerk versucht, eine Verbindung vorzunehmen.

[KingofKning]

Also wir haben hier auf unserem AD-Server ein Loginscript laufen der jedem Benutzer bei der Anmeldung das Laufwerk zuweist. Da haben wir eigentlich nie Probleme.

Früher als wir das mit der Win7 / Win10 Kiste gemachjt haben liefen wir auch ab und zu gegen die Pumpe.

Wäre evtl. eine Alternative.

GG 3515

[Fuerchau]

Davon liest man auch viel in den M$-Technetforen.
Laufwerksverknüpfung per Powershell oder GPO bei der Anmeldung verbinden.
Im Windowsumfeld klappt dies ja meist durch die 1-malige AD-Anmeldung im Netz.
Aber wer verwendet denn auf der AS/400 (IBM i) Singlesignon;-).
Ohne Singlesignon sind leider die Kennworte in den Scripten im Klartext zu hinterlegen.

Aber mit o.a. angegebenen Registry-Eintrag (geht auch per GPO) erscheint ein rotes Kreuz und beim Klick wird mit den gespeicherten Informationen dann verbunden.

[malzusrex]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\NetworkProvider
(falls nicht vorhanden als DWORD 32 erstellen) auf 0 setzen.
Dann wird erst beim Zugriff auf das Laufwerk versucht, eine Verbindung vorzunehmen.

An dem Ort müsste dann der Schlüssel
RestoreConnection als DWORD32

angelegt werden

Wenn ich mich nicht irre

Liebe Grüße
Ronald

[Fuerchau]

Das kommt davon, wenn man nur die Hälfte kopiert:
https://www.it-administrator.de/them...nt/166354.html

"Die Modifikation der Registry sorgt dafür, dass Windows nicht mehr auf die kurzfristig nicht erreichbaren Netzwerk-Laufwerke wartet. Navigieren Sie zum Eintrag "HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ NetworkProvider" und legen Sie einen neuen DWORD-Wert (32 Bit) mit der Bezeichnung "RestoreConnection" an. Der für diese Zwecke korrekte Wert "0" ist dann schon vorgegeben. Die Verbindung wird ab sofort nur noch beim ersten Zugriff auf das Laufwerk hergestellt, was sowieso praktikabler erscheint."