[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2020
    Beiträge
    5

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

    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.

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    19.435
    "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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    Aug 2006
    Beiträge
    2.007
    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

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    19.435
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    May 2002
    Beiträge
    1.117
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    19.435
    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."
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

Ähnliche Themen

  1. Get_Xml_File schlägt fehl mit SQL Code -404
    Von derMuller im Forum NEWSboard Programmierung
    Antworten: 3
    Letzter Beitrag: 13-08-19, 13:39
  2. Debian S390 Installation auf 720 schlägt fehl
    Von KingofKning im Forum NEWSboard Linux
    Antworten: 2
    Letzter Beitrag: 14-04-18, 15:38
  3. Raid5 Start schlägt fehl
    Von Hubert im Forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 13-06-17, 09:10
  4. CRTSQLPKG schlägt fehl
    Von Flappes im Forum IBM i Hauptforum
    Antworten: 11
    Letzter Beitrag: 25-07-14, 07:52
  5. VA RPG Read anweisung schlägt fehl
    Von Peter Kosel im Forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 18-10-01, 13:49

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •