[w2k] Startmenu traag door Folder redirection icm DFS

[Verwijderd]

Ik zit met het volgende probleem in een W2K AS omgeving:

In de GPO van onze gebruikers is ingesteld dat het startmenu geredirect wordt naar een map op het netwerk. Dit werkt prima. Om nu te zorgen dat het startmenu voor de gebruikers altijd beschikbaar blijft, zijn we nu aan het testen met DFS.

Ik heb de map met startmenu items gekopieerd naar een andere server en een DFS root met een link aangemaakt. Als ik nu in de GPO aangeef dat het startmenu geredirect moet worden naar de DFS link, dan wordt het startmenu voor de gebruiker gevult met de juiste items maar..... het startmenu is ENORM traag. Als je klikt op start->programs, dan moet je soms 10-20 sec wachten voordat het startmenu verder uitklapt. Ook het uitklappen van diverse subitems kan soms lang duren.

Heeft iemand hier ervaring mee?

[paulhekje]

Als je DFS alleen gebruikt binnen dezelfde AD-site kun je overwegen site awareness uit te zetten op de DFS client. Bij XPsp2 leverde dat 2 jaar geleden behoorlijke tijdwinst op.

Als dit werkt, dan weet je in ieder geval zeker dat de dfs-client zelf het probleem is

Disabling site awareness for Windows Server 2003 or for Windows 2000 DFS in a Windows NT 4.0 domain

[ Voor 27% gewijzigd door paulhekje op 11-03-2008 09:46 ]

[Verwijderd]

mmm... interessante tip. Wij gebruiken idd maar 1 site.

[paulhekje]

en welk OS gebruik je op de client? voro bijv xp zijn er losse dfs hotfixes zoals:
File list in the Windows Explorer folder is not refreshed after you create, move, or delete files

en deze is ook interessant, voor het instellen van de cachetijden:
http://blogs.technet.com/...ve/2006/01/20/417832.aspx

[ Voor 22% gewijzigd door paulhekje op 11-03-2008 09:51 ]

[Verwijderd]

De client is een W2k terminal server

[Verwijderd]

Ik heb de site awareness uitgezet, maar ik heb nog steeds hetzelfde probleem.

[Question Mark]

Waarom redirect je het startmenu niet naar een map lokaal op alle Terminal Servers?

't is wat meer werk omdat het startmenu op alle terminal servers onderhouden moet worden, maar het levert je een behoorlijke performance verbetering op. (en het onderhoud doe je vanaf één bron, die je laat syncen naar al je Terminal Servers)

Zoals ik begreep is de enige reden dat je overstapt op DFS vanwege beschikbaarheid. Dat is op deze manier ook geregeld.

[Verwijderd]

Dit is precies de opzet die we nu ook al hebben, maar wij willen het startmenu centraal plaatsen en dan redundant uitvoeren.

[Question Mark]

Verwijderd schreef op woensdag 12 maart 2008 @ 13:20:
Dit is precies de opzet die we nu ook al hebben, maar wij willen het startmenu centraal plaatsen en dan redundant uitvoeren.

In je topicstart vermeld je dat je het startmenu redirect naar een map op het netwerk. Ik interpreteer dit als een netwerkshare, vandaar de verwarring waarschijnlijk...

Ik heb geen oplossing voor je probleem, maar waarom wil je de map op een DFS plaatsen? Het aantal I/O bewerkingen op je terminal servers zal aardig toenemen (elke keer startmenu openen betekend immers het openen van een fileshare). Ook is access naar een fileshare altijd "trager" dan access naar een local disk. Volgens mij kan dat niet opgewegen tegen het kleine beheersvoordeel wat je wint.

Persoonlijk zou ik eerst het startmenu eens redirecten naar een gewone fileshare en eens flink gaan meten wat de toename aan belasting op je servers en wat de gebruikerservaring is.

[Verwijderd]

Ik heb een test uitgevoerd met een verwijzing naar een netwerk share. Dit gaat wel goed. Zodra ik echter de share opneem in de DFS, wordt het traag.

[Koffie]

Waarom redirect je het startmenu, met roaming profiles ben je er ook al; of mis ik nu iets?

[Verwijderd]

De bedoeling is dat alle gebruikers hetzelfde startmenu krijgen. Als ik het startmenu in het roaming profile zet en later iets verander, dan moet ik toch een x-tal startmenus wijzigen.

[paulhekje]

workaround: je zou het startmenu ook kunnen redirecten naar lokaal op de terminal server en vervolgens DFS alleen gebruiken om deze synchroon te houden.

[Koffie]

Verwijderd schreef op donderdag 13 maart 2008 @ 11:20:
De bedoeling is dat alle gebruikers hetzelfde startmenu krijgen. Als ik het startmenu in het roaming profile zet en later iets verander, dan moet ik toch een x-tal startmenus wijzigen.

Daar hebben ze loginscripts voor uitgevonden.
Ik wil niet lullig overkomen, maar volgens mij zit je nu krampachtig aan een techniek te denken omdat het in de eerste plaats niet goed geregeld is ?

Het start menu hoort in principe gewoon in het roaming profile, en deze beheer je met een degelijk loginscript.

[Gomez12]

Of gewoon simpelweg 1 start menu op netwerk share, dit is de source. Dan rsync / robocopy je het gewoon elke avond naar alle ts'en. Elke wijziging in je source staat een dag erna op alle ts'en.
Eigenlijk simpelweg wat de meesten hier al zeggen.

Of je script het of als dat niet je ding is koop je powerfuse.

Waarom wil je perse dfs gebruiken voor je start menu?
Het start menu vond ik vroeger altijd het minst belangrijke onderdeel van een profiel, gewoon je all users goed instellen en het enige wat mensen kwijtraken is hun eigen start instellingen binnen 1 dag / login. Nooit zo boeiend gevonden.

[Verwijderd]

Of het nu wel of niet een goeie oplossing is, kan je je wel afvragen waarom het zo traag is. Normaliter is het redirecten van een startmenu alleen traag als de verbinding niet goed is, of wellicht je dfs niet. Heb je misschien nog domain controllers in je netwerk die niet meer bestaan, en heb je de overige performance van je dfs wel goed getest en is dit snel? (als een gek rondklikken in je filestructuur bijvoorbeeld).

[Gomez12]

Verwijderd schreef op vrijdag 14 maart 2008 @ 18:23:
Of het nu wel of niet een goeie oplossing is, kan je je wel afvragen waarom het zo traag is. Normaliter is het redirecten van een startmenu alleen traag als de verbinding niet goed is, of wellicht je dfs niet. Heb je misschien nog domain controllers in je netwerk die niet meer bestaan, en heb je de overige performance van je dfs wel goed getest en is dit snel? (als een gek rondklikken in je filestructuur bijvoorbeeld).

Alhoewel je terechte vragen stelt, zie ik het als een gek rondklikken in je filestructuur als een leuke dagvulling, maar een test van niets. Maak dan een script wat gewoon de properties van een paar honderd bestanden uitleest en kijk hoe lang dit duurt, volgens mij doet het start-menu namelijk meer dan alleen maar bestanden tonen, ik dacht dat het ook nog eens specifiek rechten controleerde etc.

[Verwijderd]

reden waarom ik dat vroeg is omdat ik een probleem had vorige week bij een klant waarbij je als je rond ging klikken heel snel exporer vast leek te lopen en er grote vertragingen ontstonden. Uiteindelijk kunnen verhelpen door een registry setting aan te passen die de shadow copy explorer onderdelen hard uitschakeld.

[Workaholic]

Ik vind het zonde om hiervoor een nieuw topic te openen maar ik heb bij een klant van ons het volgende probleem.

Ik heb vorige week DFS + DFS replication aangemaakt voor het domein en alle shares via het domein/dfs principe bereikbaar gemaakt.

Dit werkt allemaal prima behalve dat het met enige regelmaat traag is via explorer.

Dit is begonnen nadat ik de login scripts had aangepast van //server naar //domein/dfs/folder

(zie voorbeeld:)

code:

iff MemberOf(ObjGroupDict, "Developers") Then
      oNetwork.RemoveNetworkDrive "L:"
      oNetwork.MapNetworkDrive "L:", "\\bedrijf\dfs\Projects"
      oShell.NameSpace("L:").Self.Name = "Projects"

Ik heb het nu weer terug gezet naar \\server en alles is weer snel. Ik herken de zaken die onder andere in dit topic worden genoemd.

Is er een bepaalde service, controle of optie die ik uit moet zetten om kwa performance dicht in de buurt kom van unc links?

Dfs is prima bereikbaar, geen errors in eventlogs, dns is prima, netwerk performance is top. Geen replicatie issue's of verkeerde links naar dode DC's.

Iemand een idee waar ik moet zoeken? Het hele principe van DFS is dat ik niet wil dat men naar een \\servernaam gaat maar naar de dfs koppeling.

Het openen van deze computer/explorer kan soms een vertraging van 10-30 sec geven.

Probleem komt hier en daar af en toe naar voren.. bij meerdere clients. Indien ik de login script terug met netwerk schijven terug zet naar \\servernaam is het weg.

[ Voor 8% gewijzigd door Workaholic op 25-06-2008 17:33 ]

[Brahiewahiewa]

Heb je al eens een netwerk trace gemaakt van 't problematische gedrag? Ik heb wel eens gezien dat een virusscanner bizarre fratsen uithaalt icm DFS (als in: de complete directory tree doorzoeken bij elke toenaderingspoging)

[Workaholic]

Ja, had ik helaas geen tijd meer voor maar dat stond sowieso op de planning.

Ik verwacht echter dat he tprobleem bij DFS zelf ligt en niet bij SMB.

Maar een trace zal ik zo snel mogelijk even doen, stel dat hier niets geks uit komt enige idee waar ik dan zou moeten kijken?

[ Voor 32% gewijzigd door Workaholic op 25-06-2008 18:04 ]

[alt-92]

Heb je dat ook als je enkel DFS namespaces gebruikt, dus zonder DFS-R?
En wat is je TTL op je DFS nodes, staan die nog default (5 minuten)?

[ Voor 33% gewijzigd door alt-92 op 27-06-2008 19:21 ]

[Tylen]

Ik zie dat je met windows 2000. Je weet dat je maar 250 current commands hebt. En dus nu je fileserver helemaal over de zeik helpt.

Monitor maar eens je current commands (in de redirector) op je fileserver, deze loopt waarschijnlijk bocven de 250 en die "hangt" ie.

Ps. Uit mijn hoofd was het 250 maar kan ook 200 wezen maar was ergens in die buurt. Mooieste oplossing is idd via login script met een robocopy script.

[svanweelden]

Workaholic schreef op woensdag 25 juni 2008 @ 17:32:
Ik vind het zonde om hiervoor een nieuw topic te openen maar ik heb bij een klant van ons het volgende probleem.

Ik heb vorige week DFS + DFS replication aangemaakt voor het domein en alle shares via het domein/dfs principe bereikbaar gemaakt.

Dit werkt allemaal prima behalve dat het met enige regelmaat traag is via explorer.

Dit is begonnen nadat ik de login scripts had aangepast van //server naar //domein/dfs/folder

(zie voorbeeld:)

code:

iff MemberOf(ObjGroupDict, "Developers") Then
      oNetwork.RemoveNetworkDrive "L:"
      oNetwork.MapNetworkDrive "L:", "\\bedrijf\dfs\Projects"
      oShell.NameSpace("L:").Self.Name = "Projects"

Ik heb het nu weer terug gezet naar \\server en alles is weer snel. Ik herken de zaken die onder andere in dit topic worden genoemd.

Is er een bepaalde service, controle of optie die ik uit moet zetten om kwa performance dicht in de buurt kom van unc links?

Dfs is prima bereikbaar, geen errors in eventlogs, dns is prima, netwerk performance is top. Geen replicatie issue's of verkeerde links naar dode DC's.

Iemand een idee waar ik moet zoeken? Het hele principe van DFS is dat ik niet wil dat men naar een \\servernaam gaat maar naar de dfs koppeling.

Het openen van deze computer/explorer kan soms een vertraging van 10-30 sec geven.

Probleem komt hier en daar af en toe naar voren.. bij meerdere clients. Indien ik de login script terug met netwerk schijven terug zet naar \\servernaam is het weg.

Wat was uiteindelijjk de oplossing voor jouw probleem?? ik ben hier erg benieuwd naar!

[sanfranjake]

Ik heb zo veel gekke inconsistenties meegemaakt met redirected folders op dfs, dat ik ze nu weer hard naar een server wijs, en die op de achtergrond repliceer.
Bij een outage van server1 kan ik dan een cnamerecord aanmaken (en de regkey for DisableStrictNameChecking uit) en de boel via server2 op dezelfde naam benaderen. Wel ranzig maar het werkt.
Een geclusterde server lijkt me nog mooier, maar daar is bij mijn mkb klantjes geen geld voor Ik heb wel gemerkt dat folder redirection icm offline files naar een dfs dus _echt_ heel slecht werkt... wellicht zag ik iets over het hoofd, bij MS iig nooit duidelijke documentatie gevonden (en een supportcase openen lag ook ver buiten het budget )

[PolarBear]

sanfranjake schreef op vrijdag 03 juli 2009 @ 14:14:
MS iig nooit duidelijke documentatie gevonden (en een supportcase openen lag ook ver buiten het budget )

Ik weet het niet zeker (want gold partner) maar ik zag dat een supportcase 350 euro kost bij MS. Als dat al buiten budget ligt is het wel heel beperkt.

[Gomez12]

PolarBear schreef op woensdag 08 juli 2009 @ 20:28:
[...]


Ik weet het niet zeker (want gold partner) maar ik zag dat een supportcase 350 euro kost bij MS. Als dat al buiten budget ligt is het wel heel beperkt.

Tja, als je een heel beperkt probleem hebt wat ook met 10 andere methodes te regelen is, dan ligt er vrij veel buiten het budget...

Je praat over 1 site met ts'en. Dan kan ik me voorstellen dat men er geen 350 voor over heeft om het startmenu iets sneller te laten gaan. Het beheersgemak is gering boven een robocopy en de noodzaak ( wat bij meerdere wan-sites wel kan spelen ) voor beheersgemak is ook gering.

En stiemem vermoed ik ook gewoon dat MS gaat komen met dat het afgeraden is om op 1 site het startmenu te redirecten naar een dfs...

[sanfranjake]

PolarBear schreef op woensdag 08 juli 2009 @ 20:28:
[...]


Ik weet het niet zeker (want gold partner) maar ik zag dat een supportcase 350 euro kost bij MS. Als dat al buiten budget ligt is het wel heel beperkt.

Bij mij in het MKB is 350 euro de waarde van een gemiddeld servicecontract (extreem kleine bedrijven). Een klant zal er echt niet voor betalen als het ook op een andere manier makkelijk en goed werkend op te lossen is. En als het niet te factureren is ga ik zelf ook niet de filantroop uithangen in deze economische tijden

Overigens is het bij een bedrijf wat maximaal enkele tientallen werkplekken heeft, wel zo redundant mogelijk wil zijn met zo min mogelijk hardware (lees: 2 windows servers, beide ook dc). Daar is het gewoon prima acceptabel dat bij uitval van de primaire fileserver de homedirectory, desktop etc even offline schieten. Offline files met XP en Vista is echt briljant.
Net als dat het in een klein bedrijfje prima acceptabel is dat wanneer de exchangeserver (vaak SBS2003/2008) er uit vliegt de mail slechts nog offline gecached is. Het is een goede oplossing voor bedrijven met weinig budget

[ Voor 45% gewijzigd door sanfranjake op 08-07-2009 21:02 ]