Bestanden aanmaken op mapping werkt niet, op UNC pad wel?

[Paul]

We hebben hier een heleboel Windows 7-machines in een domein, met een drivemapping van i: naar \\domein.local\dfsroot\share of naar \\server\share, welke van de twee maakt voor het probleem niet uit.

Hier een bestand of folder op aanmaken werkt niet:


Doe je datzelfde echter op het UNC-pad naar exact dezelfde locatie dan werkt het zonder problemen. Een bestaande map (of bestand) copy/pasten/hernoemen op de drive mapping (en op UNC) wel mag?

Het betreft een Windows Cluster met 2 nodes en dit probleem treed slechts op bij één share op het cluster, op andere shares op het cluster (ook op dezelfde node) treed dit probleem niet op. Access Based Enumeration staat aan, maar dat staat op andere shares op dezelfde node ook aan.

Mijn testgebruiker heeft op NTFS-niveau (gecontroleerd dmv Effective Permissions) 'Full Control' op die map, idem op share-niveau.

Wat kan hier aan de hand zijn?

[ Voor 7% gewijzigd door Paul op 10-10-2014 12:14 ]

[Killah_Priest]

- Is dit met 1 user of met meerdere users?
- doet dit probleem zich alleen voor op specifieke win7 machines of op alle win7 machines?
- als je een vers testaccount aanmaakt in AD en je logt daarmee in op een probleem machine heb je er dan ook last van?

En hoe wordt de drive gemapped? Login script, GPO (preference)?
En wat als je handmatig de drive map verwijdert en dmv net use opnieuw aanmaakt? En wat als je dit met een andere drive letter doet?

(Bovenstaande zijn de eerste tests die mij te binnen schieten zo even snel)

[Paul]

1) Met alle users
2) op alle Win7-machines (image komt uit SCCM, komt een VDI-specifiek sausje overheen, wordt met Citrix Provisioning Services naar een lege VM gepompt, maar ook op fat clients, zelfde image uit SCCM, fat-client sausje er overheen, wordt met PXE-boot op fat client gezet)
3) Ook met een verse user

Hoe het precies gebeurt weet ik eerlijk gezegd niet, maar mapping verbreken en opnieuw aanmaken helpt niet, ook niet met een andere letter.

Wat wel werkt is een mapping maken naar \\server\share\subfolder Dat is echter geen oplossing voor ons

[Killah_Priest]

Even voor mijn begrip : als je de drive dus rechtstreeks (dus buiten je DFS om) mapped doet het probleem zich ook voort? Op beide folder targets?
Je zou (als je de storage ervoor hebt) kunnen proberen om op een andere server een identieke share te maken en de data te replicaten en deze opnemen in je folder targets om te kijken of het probleem zich dan ook voortdoet.
Speelt het dan niet dan zou je eventueel de shares op de andere machines kunnen verwijderen en opnieuw aanmaken (en uiteraard weer opnemen in je DFS)

[Paul]

Er zijn geen meerdere targets, we gebruiken enkel DFS Namespaces, geen DFS Replication

Het probleem bestaat inderdaad zowel wanneer we op de DFS-naam als op de 'directe' naam mappen.

[Glashelder]

Wellicht kan je eens Wireshark ertussen hangen om te kijken wat er precies heen en weer verstuurd wordt? Verder ook geen meldingen in je eventviewer?

[Killah_Priest]

Anders kun je ook nog buiten productie tijden de dfs target verwijderen, folder unsharen, share opnieuw aanmaken en dfs target opnieuw toewijzen.

Nog even een andere vraag tussendoor : je mappings zijn op basis van fqdn? Dus dat ook de dfs target naar de fqdn van de fileserver verwijst bij de folder target (en wanneer je de drive mapped).
Ik heb zelf op 1 omgeving problemen gehad met netbios resolution wat verkeerd ging bij bepaalde applicaties (windows explorer oa) wat tot vage problemen leidde. Was ook alleen met 1 fileserver welke inmiddels uit productie is.
Dfs targets (en ook enkele losse shares buiten dfs om destijds) hebben we omgezet naar fqdn en dat ging wel goed

(Ik heb ook wel eens gehad dat ik een aantal shares op 1 server niet kon openen als ik de server op netbios naam benaderde. Dmv fqdn of ip werkte het wel.)

[ Voor 10% gewijzigd door Killah_Priest op 10-10-2014 21:21 ]