[2003] UNC path vs Drive mapping

[bord4kop]

Situatie:

2 lokaties
Windows 2003 servers (op hoofdlokatie)
Citrix (op hoofdlokatie)
Xp clients (op vestiging)


Probleem:
Als clients via hun citrix sessie bestanden benaderen, via hun drive mapping (bijv. K:) is er geen probleem
Doen ze echter hetzelfde buiten Citrix om, hebben ze "no acces"..

Maar als ze de share benaderen via het UNC path komen ze er WEL op!

EDIT:
Wat ook belangrijk is;
Het (UNC) path is ´\\server\data$\data_voor_loca`
De mapping naar het path is naar een DFS ´\\domain\data_voor_loca`

"EDIT 2:"
Users die op de hoofdvestiging zitten hebben géén problemen, zowel via mapping, als via UNC kunnen er gewoon op komen

De melding die users krijgen als ze de share benaderen via de drive mapping (via de K:\ schijf) is:

code:

“toegang geweigerd, mogelijk beschikt u niet over de juiste machtigingen"

[ Voor 39% gewijzigd door bord4kop op 02-06-2009 11:55 ]

[elevator]

Dat klinkt simpelweg alsof de K: drive op de client naar iets anders gemapped is dan de K: drive in de Citrix sessie?

[bord4kop]

Ja, dat was de 1e gedachte inderdaad, maar de mappings worden in 1 script gezet, die is gelijk voor zowel Citrix als `lokaal`.

Dus nee, dat is het niet.

NB: mapping gebeurt op basis van groupslidmaatschap, niet op locatie.

[ Voor 9% gewijzigd door bord4kop op 02-06-2009 10:45 ]

[elevator]

Doe eens op de Citrix sessie een 'net use' en op de client sessie een 'net use' (misschien staat er een persistent mapping op de client waardoor het logon script die niet overschrijft), verder moet je even de exacte foutmelding aangeven die de client geeft

[bord4kop]

Sorry voor de -late- edits, dat maakt het verhaal misschien anders.

Persistent is een goeie inderdaad, had ik ook al aan mijn collega gevraagd om te checken vorige week.
Schijnt dat een vorige beheerder daar wel gek op was... ik zeg maar
Maar de K: schijf verwijst naar de juiste locatie, anders zouden ze data (naam van de map) niet eens zien. Alleen daadwerkelijk in de map gaan lukt niet via K:\<map-xyz\files >

Maar e.e.a. heeft denk ik niet veel te maken met de toegang tot de data. Ik bedoel hiermee: de rechten erop en of ze wel de juiste data aan het benaderen zijn.

De data staat op 1 lokatie, alleen benaderd men in de ene situatie de data via het -directe- UNC path, in de andere via een gezette drive letter die verwijst naar de DFS van de (lokatie van de) data...

En men KAN erbij, dus de rechten zijn goed.
Het moet em zitten in een verschil tussen DFS en/of drive mapping en UNC benaderen
Maar zover ik weet is er feitelijk geen verschil, toch?

[ Voor 4% gewijzigd door bord4kop op 02-06-2009 10:59 ]

[elevator]

Het kan zo zijn dat de data gerepliceerd is naar de lokale server en dat de Citrix server naar ServerA gaat (met de juiste rechten) en dat de client naar ServerB gaat omdat die in een andere site zit (met foute rechten).

[bord4kop]

Nee helaas..

Er is maar 1 data server, de lokaties hebben geen server lokaal
Das juist het gekke aan dit verhaal

1 data server
op de hoofdloca gaat het goed, vestiging niet (maar wel wanneer er rechtsstreeks op het UNC pad wordt toegegrepen)

De enige verschillen zijn:
UNC patch vs Drive mapping (oftwel UNC vs DFS)
Vestiging vs hoofdlokatie

[ Voor 51% gewijzigd door bord4kop op 02-06-2009 11:38 ]

[elevator]

Geef echt eens de output van de 'net use' aan - dat een mapped drive letter een juist label heeft zegt helaas niet zo veel want dat label kan je editten (of kan onthouden zijn van 'vroeger').

Het zou ook nog kunnen zij dat je laptop in 'offline modus' staat, heb je dat al gechecked?

[bord4kop]

Ja, dat is gecontroleerd.
Het gaat trouwens om alle FAT-cliets op de locatie.
Ik heb de melding die men krijgt even in de SP erbij gezet, trowuens

Net use in "citrix sessie" geeft:

G: \\domain\data

K: \\domain\data\data_van_locatie

(en de H:\ (home) en andere disks)

En op lokaal

G: \\domain\data

K: \\domain\data\data_van_locatie

(en de H:\ (home) en andere disks)


En dat klopt, want het komt vanuit hetzelfde inlogscript uitgevoerd door dezelfde user, lid van dezelfde groepen. Daar zit t em niet in ben ik bang...
En ook niet in /P. Ik heb namelijk in het inlogscript eerst alle driveletters die gezet moeten worden /D gedaan
(-> /Persistent en /Delete)

[ Voor 20% gewijzigd door bord4kop op 02-06-2009 11:58 ]

[elevator]

Aha. En als je nu ipv de netbios domain name, de FQDN domainname (dus example.lan ipv example) pakt? Kan je die wel resolven, en zo ja, kan je die dan wel gebruiken op de client?

[bord4kop]

?
Dat maakt geen verschil..
Het gaat juist wél goed met het UNC path, maar niet met drive mappings/DFS

[elevator]

Nee ik bedoel, als je de drivemapping via de FQDN laat lopen? (dus: net use \\example.lan\data) ?

[bord4kop]

Dat gaat niet want het is DFS, (dat is in weze al een FQDN):
\\domain naam\data$\data_van_locatie <dit is de map van de lokatie>

Maar ik kan het inderdaad (waaarschijnlijk) oplossen door in het loginscript te verwijzen naar het UNC path en niet naar de DFS
USE K: \\server\share\data_van_locatie

Echter, dan verliezen we het nut van de DFS en daarbij weten we nog steeds niet wat de oorzaak is..
Het KAN eigenlijk niet namelijk, er MOET iets zijn, maar wat??

[elevator]

Misschien dat we naast elkaar praten, maar ik bedoel - je hebt de netbios domain naam ("EXAMPLE") en je hebt de DNS-domain name ("example.lan").

Ik zou voorstellen om de DNS domain name te gebruiken want als je geen DC hebt in een subnet en je hebt bijvoorbeeld ook geen WINS ingesteld (of die staat mis), dan is er zeker kans dat je die netbios naam niet kan resolven

[Verwijderd]

Waar staat de DFS share ? Is het een domain namespace of standalone namespace ? Het kan best zijn dat de rechten niet goed staan op de namespace share. bvb:

Namespace share is \\DC1\Share terwijl de data op \\FileServer1\Share staat. Als rechten goed staan op \\FileServer1\Share, staan ze daarom nog niet goed op de DFS namespace.

Is dat al gechecked ?

Grtz,
Thanis

[bord4kop]

elevator schreef op dinsdag 02 juni 2009 @ 13:53:
Misschien dat we naast elkaar praten, maar ik bedoel - je hebt de netbios domain naam ("EXAMPLE") en je hebt de DNS-domain name ("example.lan").

Ik zou voorstellen om de DNS domain name te gebruiken want als je geen DC hebt in een subnet en je hebt bijvoorbeeld ook geen WINS ingesteld (of die staat mis), dan is er zeker kans dat je die netbios naam niet kan resolven

Ja, helemaal mee eens. Dan kun je problemen krijgen inderdaad. Dan vind je de share niet of je vind niet de goede share. Dus de UNC verwijst niet naar de juiste plaats

Echter hier is dat juist wél het geval, de UNC is de enige juiste. De UNC gaat naar de "echte" locatie van de share (en folders erin, waar de desbetreffende data van de loca staat)
Als de users op de locatie de UNC gebruiken om bij hun data te komen gaat alles goed, ze kunnen erbij en de juiste dingen doen (openen, opslaan, etc)
Echter als ze de K:\ schijf oftwel de drive mapping oftewel de DFS gebruiken hebben ze geen toegang
De DFS kun je benaderen door \\DFS_NAAM\Share of door \\FQDN\Share, deze is echter in beide gevallen gelijk. De FDQN van de DFS = zelfde als UNC path (-> \\domain.local\share_name)

(wat ik hierboven net heb gezegd is technisch natuurlijk niet helemaal 100%, waar. De DFS heeft in feite geen FQDN, maar het komt erop neer zullen we maar zeggen )

Verwijderd schreef op dinsdag 02 juni 2009 @ 14:00:
Waar staat de DFS share ? Is het een domain namespace of standalone namespace ? Het kan best zijn dat de rechten niet goed staan op de namespace share. bvb:

Namespace share is \\DC1\Share terwijl de data op \\FileServer1\Share staat. Als rechten goed staan op \\FileServer1\Share, staan ze daarom nog niet goed op de DFS namespace.

Is dat al gechecked ?

Grtz,
Thanis

Het gaat je om de share permissies?
(NTFS) rechten kan ik namelijk niet te zetten op de DFS...(of ik heb wat gemist)
Die staan:
Authenticated users: Full
Wat in feite voldoende moet zijn, en zo stonden ze ook op de vorige locaties en staan ze op alle overige locaties in de DFS (die goed werken)
Maar goed, voor de zekerheid ook maar even "Everyone: Fc erbij gezet.

Everyone en authenticated zijn natuurlijk 2 verschillende beesten voor (Windows) shares. Zeker als de 1e keer wordt toegegrepen op een share vanuit een "user is aan het aanloggen" sessie...
De PC 's hebben overigens wel allemaal een account in het domain

EDIT:
Share permissies is feitelijk ook het 1e waar ik aan dacht toen ze me dit probleem voorlegden.
De users komen erop/kunnen erbij, alleen niet via de goede manier...

[ Voor 3% gewijzigd door bord4kop op 02-06-2009 14:24 ]

[Verwijderd]

NTFS Permissies kan je ook instellen en moet je ook zeker doen. In jouw geval moeten authenticated users minimaal "read" rechten hebben op de map die als DFS share word gedeeld (dus in mijn voorbeeld \\DC1\Share ==> C:\DFSRoots\Share bijvoorbeeld).

Grtz,
Thanis

PS: Bij een Domain namespace staan deze "per default" uiteraard niet goed als de namespace op een DC word gemaakt.

[elevator]

bord4kop schreef op dinsdag 02 juni 2009 @ 14:20:
Echter hier is dat juist wél het geval, de UNC is de enige juiste. De UNC gaat naar de "echte" locatie van de share (en folders erin, waar de desbetreffende data van de loca staat)
Als de users op de locatie de UNC gebruiken om bij hun data te komen gaat alles goed, ze kunnen erbij en de juiste dingen doen (openen, opslaan, etc)
Echter als ze de K:\ schijf oftwel de drive mapping oftewel de DFS gebruiken hebben ze geen toegang
De DFS kun je benaderen door \\DFS_NAAM\Share of door \\FQDN\Share, deze is echter in beide gevallen gelijk. De FDQN van de DFS = zelfde als UNC path (-> \\domain.local\share_name)

(wat ik hierboven net heb gezegd is technisch natuurlijk niet helemaal 100%, waar. De DFS heeft in feite geen FQDN, maar het komt erop neer zullen we maar zeggen )

Even om zeker te zijn:

Benadering via	Naar	Werkt
UNC in Start->Run	\\server.domain.lan\share	Ja
Drive mapping	\\server.domain.lan\share	Ja
Locatie in Start->run	\\domain.lan\dfsshare	Ja
Drive mapping naar	\\domain.lan\dfsshare	Nee

Want dan snap ik het ook niet meer

[bord4kop]

elevator schreef op dinsdag 02 juni 2009 @ 14:37:
[...]

Even om zeker te zijn:

Benadering via	Naar	Werkt
UNC in Start->Run	\\server.domain.lan\share	Ja
Drive mapping	\\server.domain.lan\share	Ja
Locatie in Start->run	\\domain.lan\dfsshare	Ja
Drive mapping naar	\\domain.lan\dfsshare	Nee

Want dan snap ik het ook niet meer

Bijna:

Benadering via	Naar	Werkt
UNC in Start->Run	\\server.domain.lan\share	Ja
Drive mapping	\\server.domain.lan\share	Ja

Klopt niet..

dit is de drive mapping in het logon script:

Benadering via	Naar	Werkt
Drive mapping	\\domain.lan\dfsshare	NEE

verder

Benadering via	Naar	Werkt
Locatie in Start->run	\\domain.lan\dfsshare	NEE
Drive mapping naar	\\domain.lan\dfsshare	Nee

Maar als ik dit in het login script doe:

Benadering via	Naar	Werkt
Drive mapping	\\server.domain.lan\share	Ja

Werkt het ook.

Enne als men op de hoofdvestiging zit werkt het allemaal, dus ook met de "\\domain.lan\dfsshare"
Met dezelfde laptop als op de vestiging

Ik kan nergens NTFS rechten opgeven, direct op de DFS, alleen share permissions. En dit dan ook alleen op de server waar de ´hoofdmap´ van de DFS woont. Op de DC kan ik helemaal niets.
Natuurlijk wel op de mappen op de server zelf (dus dáár waar de DFS naartoe wijst)

Misschien maakt de pic e.e.a. meer duidelijk?

[ Voor 14% gewijzigd door bord4kop op 02-06-2009 15:00 ]

[elevator]

bord4kop schreef op dinsdag 02 juni 2009 @ 14:54:
Enne als men op de hoofdvestiging zit werkt het allemaal, dus ook met de "\\domain.lan\dfsshare"
Met dezelfde laptop als op de vestiging

Dus samenvattend is het zo dat DFS niet werkt op een vestiging?

Als je simpelweg pingt naar 'domain.lan' op de client op die site, krijg je dan wel hetzelfde IP adres te zien als op de hoofdsite of resolved dat bv. niet goed ofzo?

[Verwijderd]

Enne als men op de hoofdvestiging zit werkt het allemaal, dus ook met de "\\domain.lan\dfsshare"
Met dezelfde laptop als op de vestiging

Ik kan nergens NTFS rechten opgeven, direct op de DFS, alleen share permissions. En dit dan ook alleen op de server waar de ´hoofdmap´ van de DFS woont. Op de DC kan ik helemaal niets.
Natuurlijk wel op de mappen op de server zelf (dus dáár waar de DFS naartoe wijst)

Misschien maakt de pic e.e.a. meer duidelijk?

[afbeelding]

De XP gebruikers op de remote locatie, die zitten toch ook in je AD domein (dus hun lokale stations waar Citrix op draait ?), indien niet ... dan zal DFS niet (goed) werken. Indien wel, check DNS settings. Rechten zal het niet zijn aangezien de DFS share wél gemapped kan worden op de hoofdlokatie.

Is het subnet van de 2de lokatie gekend in AD Sites & Services ? Zo neen, zeker bijvoegen want DFS gebruikt site awareness etc ...

[alt-92]

offtopic:
Ps: authenticated users én everyone op de share permissies?
Heeft totaal geen zin, die zijn effectief hetzelfde.
Maak het jezelf en het troubleshooten makkelijker en gebruik de default everyone groep.
Wat je daarmee namelijk zegt is "ik doe niks met share permissies, maar handel alles via NTFS permissies af".

[bord4kop]

elevator schreef op dinsdag 02 juni 2009 @ 16:15:
[...]

Dus samenvattend is het zo dat DFS niet werkt op een vestiging?

Klopt, daar komt het op neer, maar ook weer niet helemaal...
De andere DFS-en werken namelijk wél!
Zelfde share, maar andere subfolder(s) ervan, dus
\\domain.local\DFSshare\map_van_de_locatie_van<werkmaatschappij A> werkt niet
\\domain.local\DFSshare\map_van_de_locatie_van <werkmaatschappij B> werkt wel
\\domain.local\DFSshare\map_van_de_locatie <algemeen> werkt wel
etc.

De map is verplaatst op de server, DFS aangepast naar nieuwe locatie op de server. Rechten zijn 1-op-1 kopie.
Dit klopt allemaal omdat de users er ook gewoon bij kunnen, alleen niet via de DFS als ze op loca zitten

Als je simpelweg pingt naar 'domain.lan' op de client op die site, krijg je dan wel hetzelfde IP adres te zien als op de hoofdsite of resolved dat bv. niet goed ofzo?

Pingen naar de share?

Verwijderd schreef op dinsdag 02 juni 2009 @ 17:09:
[...]


De XP gebruikers op de remote locatie, die zitten toch ook in je AD domein (dus hun lokale stations waar Citrix op draait ?), indien niet ... dan zal DFS niet (goed) werken. Indien wel, check DNS settings. Rechten zal het niet zijn aangezien de DFS share wél gemapped kan worden op de hoofdlokatie.

Is het subnet van de 2de lokatie gekend in AD Sites & Services ? Zo neen, zeker bijvoegen want DFS gebruikt site awareness etc ...

Ok, dat kan ik nog checken.
De DFS root woont (sync) op 2 verschillende servers tbv backup-2-disk. De share waar het om gaat staat maar op 1 server (hij synced dus niet naar andere een server) zie plaatje.
Alle servers wonen op de hoofdlokatie.

offtopic:
@alt-92
Yep, das bekend. We regelen toegang uiteraard dmv NTFS rechten.
Everyone en authenticated is niet hetzelfde hoor
* bord4kop vind everyone ook makkelijker

[alt-92]

Je kan eens controleren of je dfs link wel correct naar de share verwijst aangezien je zegt dat ie verplaatst is..:

D:\>dfsquery \\bozeman\data\isos
Report for: \\ALT-92\Data\isos
Storages: 1
Comment:
Timeout: 1800
Target Online :  \\BOZEMAN\isos

Kun je dit tooltje voor gebruiken.

Eventueel vraag je ook aan de client kant een uitdraai op, desnoods een output van DFSUtil /pktinfo.
Als die gewijzigde link nog met stale info in de DFS client cache staat kun je deze problemen ook krijgen.

[ Voor 29% gewijzigd door alt-92 op 03-06-2009 08:16 ]

[bord4kop]

Right, ik ben weer bij de klant

Uitkomst van dfs (tool) is:

lokatie?	DFS	fysiek pad	oud / nieuw	offline / online
hoofdsite	\\domain.local\data\data_van_lokatie	\\server\data$\ data_van_lokatie	oud	offline
hoofdsite	\\domain.local\data2\data_van_lokatie	\\server\data2$\ data_van_lokatie	nieuw	online
vestiging	\\domain.local\data\data_van_lokatie	\\server\data$\ data_van_lokatie	oud	offline
vestiging	\\domain.local\data2\data_van_lokatie	\\server\data2$\ data_van_lokatie	nieuw	online

Of met andere woorden;
De oude share is offline in DFS.
En DFS is op beide locaties exact hetzelfde...

Nou hoor ik net dat er een iShared Appliance tussen de vestigingen en de hoofdsite staat.
Dit ding schijnt te cachen zodat de vestigingen niet constant alle data over de lijn hoeven te trekken.
In feite ook een soort DFS achtig iets dus?

Hmmm... dat is echter nog geen verklaring voor het feit dat de andere (en oude) DFS-en wel gewoon werken!
Zelfde rechten, zelfde DFS instellingen, zelfde locaties dus ook \\server\data2$\andere_data_van_locatie

[alt-92]

http://blogs.technet.com/...om-dfs-access-denial.aspx

Misschien kun je daar ook nog wat mee?

[bord4kop]

Das interessant leesvoer!
Weer wat geleerd Toch leuk om te lezen hoe sommigen precies tot oorzaak en gevolg komen...
(maar niet van toepassing omdat er effectief maar 1 share is, 1 server waar alle DFS-en op wonen)

Goed wat is de status vandaag;
alles werkt

WAT??
Ja, alles werkt.

En hoe kan dat nu?
Het enige dat ik kan verzinnen is dat de cache op "DFS-server" en die op de iShared is geleegd en opnieuw opgebouwd. Want ik heb dit weekend een script laten draaien die alle servers heeft gereboot.

Wel jammer dat ik nu nog niet precies weet wat de oorzaak was en hoe dit nu precies opgelost is

[alt-92]

Dat tooltje van mij vraagt de info uit op je DFSRoot server, DFSutil /pktinfo laat de client cache op je werkstations (en andere servers) zien.
Als daar verschillen in zitten (default wordt de dfs client cache op een werkstation en server bij een reboot geleegd) kun je beide resultaten naast elkaar leggen.

Ik vermoed dat de cache op je lokaties niet bijgewerkt is na je wijzigingen, maar da's vissen in troebel water nu

[sanfranjake]

1 misschien overbodige opmerking: maar als je Symantec Endpoint Protection 11 tot MR4MP2 draait kan dit de oorzaak van dit soort gekkigheid ook zijn. Ik heb nu al bij zes klanten dit soort issues gehad (ook bij een niet-sbs klant)
http://msmvps.com/blogs/b...ally-does-other-than.aspx