none
Nach deployment kein Zugriff Samba Freigabe RRS feed

  • Frage

  • Hallo,

    Umgebung:
    MDT 2012 Update1 auf Windows Server 2008 R2 SP1

    Ich habe ein sehr merkwürdiges Problem und kann nachdem ich ein gecapurtes Image auf einen Computer aufspiele nicht auf eine Samba Freigabe zugreifen, die keine Authentifizierung erfordert (GUEST=YES).

    Ich installiere über MDT die Windows 7 SP1 RTM .iso auf einen Client. Nach der Installation kann ich problemlos, wie von jedem Computer aus, auf die Samba Freigabe zugreifen. Jetzt sysprepe und capture ich die Installation über das Sysprep and Capture Template von MDT. Anschließend spiele ich das erfasste Image mit der Standard Client Task Sequence wieder auf den Client. Das Aufspielen läuft fehlerfrei durch, aber ich kann nicht auf die Samba Freigabe zugreifen. Ich gebe im Explorer \\servername oder \\ip-adresse ein und erhalte folgende Fehlermeldung: Der Remoteprozeduraufruf ist fehlgeschlagen und wurde nicht ausgeführt. Ich kann den Servernamen und die IP-Adresse pingen. Jede andere Netzwerk Konnektivität funktioniert tadellos. Freigaben, die eine Authentifizierung erfordern kann ich aufrufen.

    Ich kann mir den Fehler nicht erklären und brauche einen helfenden Tipp. Ich bin um jeden Rat dankbar.

    Viele Grüße,

    Dienstag, 27. August 2013 08:15

Antworten

  • ApplyGPOPack=NO in der customsettings.ini setzen und dann klappt wieder alles.

    Hast du vielleicht MDT 2012 Update 1? Das ist ein 2012er Feature.

    Mittwoch, 28. August 2013 15:57

Alle Antworten

  • verwende ein Kennwort?

    Evtl. hilft auch die Änderung der Sicherheitsoptionen:
    Konten: Lokale Kontenverwendung von leeren Kennwörtern auf Konsolenanmeldung beschränken, denn die ist aktiviert.


    Tschö
    Mark Heitbrink - MVP Windows Server - Group Policy
    Homepage: www.gruppenrichtlinien.de - deutsch
    GPO Tool: www.reg2xml.com - Registry Export File Converter

    Dienstag, 27. August 2013 20:17
  • Danke für deine Antwort.

    Es gibt kein Kennwort, welches ich für die Authentifizierung verwenden kann. Der Zugriff erfolgt ohne Probleme von allen anderen Computern, die nicht über den oben genannten Weg deployt wurden, egal welches Betriebssystem.

    Die Änderung der Sicherheitsoption hat leider nicht geholfen.

    Mittwoch, 28. August 2013 07:51
  • Setzt MDT in irgendeiner Form Group Policies? Normalerweise sind die Clients in meiner Domäne so eingestellt, dass der letzte Benutzername noch im Anmeldefenster steht und man nur noch das Passwort eintragen muss. Mit dem deployten Client muss man Benutzername und Passwort eintragen. Da scheinen wohl durch MDT Gruppenrichtlinien verändert zu werden. Strange.

    Mittwoch, 28. August 2013 08:29
  • In deiner unattended.xml ist ein Autologin.

    Schau mal unter oobe -> Shell-Setup -> Autologon

    Der Wert wird am Ende der Tasksequent AFAIR wieder gelöscht und dann steht "kein" Name mehr drin. 


    Tschö
    Mark Heitbrink - MVP Windows Server - Group Policy
    Homepage: www.gruppenrichtlinien.de - deutsch
    GPO Tool: www.reg2xml.com - Registry Export File Converter

    Mittwoch, 28. August 2013 08:46
  • http://blogs.technet.com/b/deploymentguys/archive/2011/12/02/mdt-2012-new-features-gpo-packs.aspx
    Das scheint das Problem. Ich teste das gerade, indem ich ApplyGPOPack=NO in der customsettings.ini eintrage. Ich melde mich, wenn das erfolgreich ist.
    Mittwoch, 28. August 2013 13:39
  • Ich wundere mich, daß das bei mir nie angewendet wird, obwohl ich weder ApplyGPOPack=NO gesetzt habe, noch es in der TS ausschalte ...


    Tschö
    Mark Heitbrink - MVP Windows Server - Group Policy
    Homepage: www.gruppenrichtlinien.de - deutsch
    GPO Tool: www.reg2xml.com - Registry Export File Converter

    Mittwoch, 28. August 2013 14:57
  • ApplyGPOPack=NO in der customsettings.ini setzen und dann klappt wieder alles.

    Hast du vielleicht MDT 2012 Update 1? Das ist ein 2012er Feature.

    Mittwoch, 28. August 2013 15:57
  • Es ist 2012 SP1. Das LocalGPO Pack aus dem SCM würde ich auf keinen Fall anwenden wollen, das hat in einer "ordnetlichen" AD Infratruktur nichts zu suchen.

    Deswegen gibt es ja Gruppenrichtlinien im AD, damit sie nicht LOCAL verwaltet weerden müssen.

    Gleich mal den Mist in allen Shares löschen ... DANKE!


    Tschö
    Mark Heitbrink - MVP Windows Server - Group Policy
    Homepage: www.gruppenrichtlinien.de - deutsch
    GPO Tool: www.reg2xml.com - Registry Export File Converter

    Mittwoch, 28. August 2013 18:50