[AD/W2K3] Netwerkdrive mappen afhankelijk van Group

[BikkelZ]

Ik heb een kleine AD opgezet hier, roaming profiles etc.werkt allemaal prima, automatisch aanmelden van een of meer printers lukt me via scripts, maar ik wil eigenlijk het volgende, en ik heb het idee dat ik iets gigantisch over het hoofd zie:

De groep marketing moet een gedeelde share marketing hebben, systeembeheer een gezamelijke share systeembeheer, etcetera.

Dat lukt me niet met een logon script, en ik vind even in de AD Users and Computers ook geen mogelijkheid om er voor te zorgen dat een user group automatisch een bepaalde share gemapt krijgt.

[m3gA]

Je kunt kix hiervoor gebruiken (in het inlogscript)

code:

If InGroup ("MARKETING")
   Use G: /DELETE
   Use G: "\\SERVER\MARKETING"
EndIf

Met dit stukje code krijgt iedereen die in de groep "marketing" zit een g: drive die naar \\SERVER\MARKETING verwijst.
Het stukje "Use G: /DELETE" haalt de share eerst weg voor het geval dat iemand van afdeling veranderd is en het niet lukt de mapping aan te maken omdat deze al bestaat.

[ Voor 31% gewijzigd door m3gA op 10-11-2006 10:24 ]

[BikkelZ]

m3gA schreef op vrijdag 10 november 2006 @ 10:22:
Je kunt kix hiervoor gebruiken (in het inlogscript)

code:

If InGroup ("MARKETING")
   Use G: /DELETE
   Use G: "\\SERVER\MARKETING"
EndIf

Met dit stukje code krijgt iedereen die in de groep "marketing" zit een g: drive die naar \\SERVER\MARKETING verwijst.
Het stukje "Use G: /DELETE" haalt de share eerst weg voor het geval dat iemand van afdeling veranderd is en het niet lukt de mapping aan te maken omdat deze al bestaat.

Dat ziet er op zich logisch uit, maar dat vereist dat ik bepaalde dll's bij mijn clients krijg via NETLOGON, da's nog ff puzzelen.

Ik heb zowel Novell als Active Directory kort na elkaar gehad, was dit dan iets wat wél simpel te regelen was in Novell?

[djluc]

Wat je kan doen is: Je zet de shares in je AD middels share objects. Dit is eigenlijk alleen maar een object op mee te organiseren, die mappen dus niet zelf. Wat je echter kan doen is een logonscript maken wat zoekt naar mappen in de OU van de user en deze dan mapt. Het enige beheer wat je dan hebt is gewoon die objecten in AD aanmaken. Werkt prima!

[BikkelZ]

djluc schreef op vrijdag 10 november 2006 @ 10:37:
Wat je kan doen is: Je zet de shares in je AD middels share objects. Dit is eigenlijk alleen maar een object op mee te organiseren, die mappen dus niet zelf. Wat je echter kan doen is een logonscript maken wat zoekt naar mappen in de OU van de user en deze dan mapt. Het enige beheer wat je dan hebt is gewoon die objecten in AD aanmaken. Werkt prima!

Dit klinkt wel als een nettere manier om dit te doen, ik heb inderdaad de users van de verschillende groepen onder gebracht in eigen OU's, en het zou fijn zijn als drives en eventueel printers die ik ook in die OU onder heb gebracht automatisch gevonden en gemapt worden.

Heb je een kleine hint van hoe zo'n script er ongeveer uit ziet?

[ZeRoC00L]

Waarom kix ??
Je kunt toch ook een VB script maken ?

[djluc]

Gewoon een LDAP query uitvoeren, zijn enorm veel voorbeelden van. Het interessante is dan: "where objectClass='volume' " waarmee je dus alleen de shares krijgt. Vervolgens gewoon mappen. Ik kijk of de sharenaam het woord 'printer' bevat. Indien dit zo is installeer ik de share als printer anders als map, dat is gewoon een simpele snelkoppeling op het bureaublad.

[BikkelZ]

Ik heb nu dit:

VBScript:

'on error resume next

Dim strOU, arrPath, intLength, intNameLength, strUser, ding, comma

comma = ""

'find the user AD path
Set objSysInfo = CreateObject("ADSystemInfo")
strUser = objSysInfo.UserName
wscript.echo strUser
arrPath = Split(strUser, ",")
For Each ding in arrPath
    Wscript.Echo Left(ding, 3)
    If Left(ding, 3) ="OU=" Then
        strOU = strOU & comma & ding
        comma =","
    End If
    If Left(ding, 3) ="DC=" Then
        strOU = strOU & comma & ding
        comma =","
    End If
Next
wscript.echo "LDAP://" & strOU

Set objOU = GetObject("LDAP://" & strOU)
objOU.Filter = Array("printer", "volume")

For Each objItem in objOU
    Wscript.Echo "iets"
Next

Array("user") moet duidelijk iets van Array("printer", "volume") worden. Maar ik krijg de OU dus niet te pakken op dit moment.

=========

Waarschijnlijk gaat het fout omdat ik een OU in een OU heb en alleen de OU pak waar hij direct in ligt, ik ga even kijken of ik het script aan de praat krijg. DC's hoeven niet opgegeven te worden als er maar een is, namelijk degene waarop de user is aangelogd, toch?

=========

OK, hij begint nu met "iets" te echoen, en afhankelijk van wat ik in de Array prop krijg ik het correcte aantal te zien. Nu nog even scheiden tussen printers en volumes, en die automatisch aankoppelen, en ik ben klaar.

Wel vraag ik me af wat ik moet doen als iemand in meer groepen zit.

[ Voor 48% gewijzigd door BikkelZ op 10-11-2006 11:41 ]

[m3gA]

BikkelZ schreef op vrijdag 10 november 2006 @ 10:31:
[...]


Dat ziet er op zich logisch uit, maar dat vereist dat ik bepaalde dll's bij mijn clients krijg via NETLOGON, da's nog ff puzzelen.

Ik heb zowel Novell als Active Directory kort na elkaar gehad, was dit dan iets wat wél simpel te regelen was in Novell?

kix32.exe in de netlogon zetten en dan aanroepen in het inlogscript via kix32 login.kix ofzo
je hoeft echt geen dll's te gebruiken.

[djluc]

Je kunt maar in 1 OU zitten, groepen hebben hier verder niets mee te maken?

[Verwijderd]

m3gA schreef op vrijdag 10 november 2006 @ 10:22:
Je kunt kix hiervoor gebruiken (in het inlogscript)

code:

If InGroup ("MARKETING")
   Use G: /DELETE
   Use G: "\\SERVER\MARKETING"
EndIf

Met dit stukje code krijgt iedereen die in de groep "marketing" zit een g: drive die naar \\SERVER\MARKETING verwijst.
Het stukje "Use G: /DELETE" haalt de share eerst weg voor het geval dat iemand van afdeling veranderd is en het niet lukt de mapping aan te maken omdat deze al bestaat.

kix is natuurlijk zwaar verouderd en ook overbodig. batch kan dit al, en met vbs kom je nog verder...

vb. batch

code:

net group "marketing" /domain|find /i "%username%"
if errorlevel 1 goto next
     net use g: /d
     net use g: \\server\marketing
:next
net group "hrm" /domain|find  etc etc etc

[djluc]

Je moet je vooral afvragen of je hier je security group voor wilt gebruiken. Ik vind het beheren in OU's veel handiger bijvoorbeeld omdat je veel meer overzicht hebt.

[Verwijderd]

djluc schreef op vrijdag 10 november 2006 @ 14:20:
Je moet je vooral afvragen of je hier je security group voor wilt gebruiken. Ik vind het beheren in OU's veel handiger bijvoorbeeld omdat je veel meer overzicht hebt.

jaja, je weet niet waar je over praat.
resources ken je nooit toe aan een ou, want een ou is een logische groep van resources/users/groups/computers.

en dan nog het praktische voorbeeld:

gebruiker A moet share1 en share2 hebben.
gebruiker B moet share1 hebben.
gebruiker C moet share2 hebben.

jij maakt dan 3 OU's? >> dat zou nog kunnen. maar dan moet gebruiker A printer1 hebben, B printer2 en C printer3 >> werkt ook nog.
Gebruiker D moet dezelfde shares gebruiken als A, maar met de printer van B, E heeft share1 nodig en printer 1, etc etc. oftewel voor elke combinatie van resources die je hebt, zou je in principe een ou creeren... over overzicht gesproken LMAO.

security groups is the way to go, voor het uitdelen van rechten op resources.

[ Voor 20% gewijzigd door Verwijderd op 10-11-2006 14:42 ]

[djluc]

Mm, ik heb bijvoorbeeld het volgende

code:

ROOT
  |_computers
  | |_kantoor1
  | |_kantoor2
  |_users
    |_management
    |_personeel

Het management zit in kantoor 1, stel nou dat we het volgende willen:

Managent:
- Printers: Printer kantoor 1 + Algemene printer
- Data: Groepsmap management + Algemene map.

Personeel:
- Printers: Printer kantoor 2 + Algemene printer
- Data: Groepsmap management + Algemene map.

Die algemene map en printer zet je dus onder root. De printers in de computer OU's en de groupsmappen onder de user OU's. Dat moet voldoende zijn om ze te mappen toch? Mocht je echt gekke uitbreidingen krijgen zoals: afdeling X moet ook in groepsmap afdeling Y komen moet je eerder gaan overwegen om die map een niveau omhoog te verplaatsen.

Zo heb je lekker duidelijk overzicht omdat je altijd alle mappen boven de OU toegewezen krijgt.

offtopic:
Overigens niet dat ik je kennis betwijfel o.i.d. he, je hebt al vaak in topics meesterlijke oplossingen gegeven Dus gewoon ter discussie

[BikkelZ]

Verwijderd schreef op vrijdag 10 november 2006 @ 14:34:
[...]


jaja, je weet niet waar je over praat.
resources ken je nooit toe aan een ou, want een ou is een logische groep van resources/users/groups/computers.

en dan nog het praktische voorbeeld:

gebruiker A moet share1 en share2 hebben.
gebruiker B moet share1 hebben.
gebruiker C moet share2 hebben.

jij maakt dan 3 OU's? >> dat zou nog kunnen. maar dan moet gebruiker A printer1 hebben, B printer2 en C printer3 >> werkt ook nog.
Gebruiker D moet dezelfde shares gebruiken als A, maar met de printer van B, E heeft share1 nodig en printer 1, etc etc. oftewel voor elke combinatie van resources die je hebt, zou je in principe een ou creeren... over overzicht gesproken LMAO.

security groups is the way to go, voor het uitdelen van rechten op resources.

Ja, want ik wil in principe ook mensen hebben die zowel bij marketing als bij finance kunnen omdat ze bezig zijn met een jaarverslag, even uit de lucht gegrepen voorbeeld maar goed, ik wil dan gewoon tijdelijk een user onder twee groepen zetten en dus van allebij die groepen shares laten erven.

Sowieso ben ik er niet zo dol op om hard driveletters toe te wijzen, maar het lijkt me wel scriptmatig op te lossen dat je checkt welke letters vanaf bijvoorbeeld N: al in gebruik zijn en bij de eerste vrije letter pas je drive mount.

[djluc]

Dan heeft je marketing department dus ineens toegang tot alle data die eigenlijk alleen bestemd is voor de financiele afdeling. Je moet je serieus afvragen of dat wel echt je bedoeling is!

[ZeRoC00L]

Waarom maak je verschillende shares ?
Ik zie dat het een (vrij) kleine omgeving is, ik neem aan 1 server. Maar daarop 1 share (data). en maak daarop verschillende (afdelings-)folders en regel met NTFS rechten dat de juiste mensen er wel of niet bij mogen. Je heb dan als voordeel dat iedereen die schijf als dezelfde letter heeft, wel zo makkelijk als ze documenten gaan elkaar gaan koppelen.

[djluc]

Dat is inderdaad ook een leuke oplossing, maar zien ze dan niet enorm veel mapjes waar ze niet in mogen? Of zorg je er voor dat die helemaal niet zichtbaar zijn?

[Question Mark]

djluc schreef op vrijdag 10 november 2006 @ 16:04:
Dat is inderdaad ook een leuke oplossing, maar zien ze dan niet enorm veel mapjes waar ze niet in mogen? Of zorg je er voor dat die helemaal niet zichtbaar zijn?

Acces Based Enumeration.

Windows Server 2003 Access-based Enumeration makes visible only those files or folders that the user has the rights to access. When Access-based Enumeration is enabled, Windows will not display files or folders that the user does not have the rights to access. This download provides a GUI and a CLI that enables this feature.

[Verwijderd]

djluc schreef op vrijdag 10 november 2006 @ 15:02:
Mm, ik heb bijvoorbeeld het volgende

code:

ROOT
  |_computers
  | |_kantoor1
  | |_kantoor2
  |_users
    |_management
    |_personeel

Het management zit in kantoor 1, stel nou dat we het volgende willen:

Managent:
- Printers: Printer kantoor 1 + Algemene printer
- Data: Groepsmap management + Algemene map.

Personeel:
- Printers: Printer kantoor 2 + Algemene printer
- Data: Groepsmap management + Algemene map.

Die algemene map en printer zet je dus onder root. De printers in de computer OU's en de groupsmappen onder de user OU's. Dat moet voldoende zijn om ze te mappen toch? Mocht je echt gekke uitbreidingen krijgen zoals: afdeling X moet ook in groepsmap afdeling Y komen moet je eerder gaan overwegen om die map een niveau omhoog te verplaatsen.

Zo heb je lekker duidelijk overzicht omdat je altijd alle mappen boven de OU toegewezen krijgt.

offtopic:
Overigens niet dat ik je kennis betwijfel o.i.d. he, je hebt al vaak in topics meesterlijke oplossingen gegeven Dus gewoon ter discussie

Dit werkt in een kleine omgeving vast, maar in grote omgevingen is dit simpelweg onmogelijk. Ik ken omgevingen met duizenden shares en honderden printers en wisselende werkplekken/locaties voor werknemers. Dat ga je echt niet meer lukken om met een simpele ou structuur shares uit te delen aan users binnen ou's.
De OU structuur gebruik je dan ook om policies door te voeren (zeg maar de globale rechten) en niet om resources beschikbaar te stellen.
Ik snap ook niet waarom je dat anders zou doen, je hebt de groepen toch nodig om rechten uit te delen op de resources. Een ou kan je niet koppelen aan een resource (je voorbeeldje van de user verplaatsen werkt dus ook niet, zonder de user ook in de juiste groep te plaatsen).

[BikkelZ]

Hoe zorg ik er dus voor dat ik automatisch bepaalde printers en/of drives kan koppelen afhankelijk van welke user groups iemand lid is? Groups rechten geven is geen punt, maar het automatisch mounten van een of meer printers en / of drives waar ze recht op hebben, dat lijkt eigenlijk niet zo goed ontwikkeld te zijn in AD....

[Verwijderd]

BikkelZ schreef op vrijdag 10 november 2006 @ 15:17:
[...]
Sowieso ben ik er niet zo dol op om hard driveletters toe te wijzen, maar het lijkt me wel scriptmatig op te lossen dat je checkt welke letters vanaf bijvoorbeeld N: al in gebruik zijn en bij de eerste vrije letter pas je drive mount.

je kan beter hard driveletters koppelen, omdat gebruikers komen met problemen als " mijn p schijf doet het niet". als je dan dynamisch driveletters koppelt... succes met zoeken

[Verwijderd]

Printers kun je toch met de printmanager aan een OU koppelen?
Bijv.computers 1e verdieping links in een OU 1e verdieping rechts in een OU en daar de printers aanhangen.
http://www.windowsnetwork...s-Group-Policy-Part1.html
http://www.windowsnetwork...s-Group-Policy-Part2.html
en
http://www.windowsnetwork...up-Policy-Windows-R2.html
Is wel deels voor windows 2003 R2

[alt-92]

Verwijderd schreef op zondag 12 november 2006 @ 15:41:
Printers kun je toch met de printmanager aan een OU koppelen?
[...]
Is wel deels voor windows 2003 R2

Komt er ook in met SP2 (en die is nu bij beta2 inmiddels, verwacht die q1 2007).

[BikkelZ]

Dus waarschijnlijk kan ik het beste 1 share aanmaken, daar verschillende mappen in zetten en de rechten daarop via de groups doen?

[alt-92]

Dat kan, maar dan moet je de drivemapping op een dieper nivo scripten.
dus:
\\server\share\dir1 , \\server\share\dir2 enz...

Maar haal je nu niet share\folder nesting door elkaar met OU nesting?

[BikkelZ]

alt-92 schreef op zondag 12 november 2006 @ 23:39:
Dat kan, maar dan moet je de drivemapping op een dieper nivo scripten.
dus:
\\server\share\dir1 , \\server\share\dir2 enz...

Maar haal je nu niet share\folder nesting door elkaar met OU nesting?

Nee, groups krijgen rechten op bepaalde mappen, en iedere user op het netwerk krijgt de root van die share gemapt. Met het hier aangedragen tooltje waarmee je mappen waar je niks te zoeken hebt qua rechten kunt verbergen lijkt het me dé manier om er voor te zorgen dat iedereen in de groepsmappen komt waar die persoon onder valt.

Als je het via de OU folder doet (zie script) dan heb je een probleem als je in twee groups zit in plaats van één. En bovendien wordt er hier liever theoretisch gebabbeld dan dat er iemand even naar een scriptje kijkt waar één regel fout in zit

[Verwijderd]

[message=26822426,noline]Dat lukt me niet met een logon script,

VBS script per OU in de policies knallen.

En dan per afdeling een mapping naar de juiste share, bijv.

code:

Option Explicit

Dim objNetwork, strRemotePath1
Dim strDriveLetter1
strDriveLetter1 = "F:"

strRemotePath1 = "\\SERVER1\Groupshares\Systeembeheer"

Set objNetwork = WScript.CreateObject("WScript.Network") 

objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
On Error Resume Next

WScript.Quit

[Verwijderd]

BikkelZ schreef op maandag 13 november 2006 @ 15:23:
[...]


Nee, groups krijgen rechten op bepaalde mappen, en iedere user op het netwerk krijgt de root van die share gemapt. Met het hier aangedragen tooltje waarmee je mappen waar je niks te zoeken hebt qua rechten kunt verbergen lijkt het me dé manier om er voor te zorgen dat iedereen in de groepsmappen komt waar die persoon onder valt.

Als je het via de OU folder doet (zie script) dan heb je een probleem als je in twee groups zit in plaats van één. En bovendien wordt er hier liever theoretisch gebabbeld dan dat er iemand even naar een scriptje kijkt waar één regel fout in zit

Dit is leuk als je een relatief klein bedrijf hebt. Als je data 5 TB is, zou ik toch liever verschillende shares maken op verschillende disksets. evt weer in een dfs root gooien

[BikkelZ]

Verwijderd schreef op dinsdag 14 november 2006 @ 14:08:
[...]


VBS script per OU in de policies knallen.

En dan per afdeling een mapping naar de juiste share, bijv.

code:

Option Explicit

Dim objNetwork, strRemotePath1
Dim strDriveLetter1
strDriveLetter1 = "F:"

strRemotePath1 = "\\SERVER1\Groupshares\Systeembeheer"

Set objNetwork = WScript.CreateObject("WScript.Network") 

objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
On Error Resume Next

WScript.Quit

Dat klinkt op zich wel goed, maar stel dus dat je toegang tot meerdere shares of mappen moet hebben, dan werkt dat niet lekker, aangezien je altijd maar in één OU zit.

Verwijderd schreef op dinsdag 14 november 2006 @ 14:58:
[...]


Dit is leuk als je een relatief klein bedrijf hebt. Als je data 5 TB is, zou ik toch liever verschillende shares maken op verschillende disksets. evt weer in een dfs root gooien

Nee zo groot zal het niet worden voordat het moment dat er uberhaupt een update aan de AD structuur moet komen.

[ Voor 22% gewijzigd door BikkelZ op 14-11-2006 15:53 ]

[Verwijderd]

BikkelZ schreef op dinsdag 14 november 2006 @ 15:52:
[...]


Dat klinkt op zich wel goed, maar stel dus dat je toegang tot meerdere shares of mappen moet hebben, dan werkt dat niet lekker, aangezien je altijd maar in één OU zit.

Werkt prima, heb het hier ook zo draaien. Je moet alleen per afdeling een loginscript maken en per afdeling in de grouppolicies zetten. Het printerverhaal kun je in dezelfde scripts zetten.

wat uitgebreider wat betreft de mappings;

code:

Option Explicit

Dim objNetwork, strRemotePath1, strRemotePath2, strRemotePath3
Dim strDriveLetter1,strDriveLetter2, strDriveLetter3
strDriveLetter1 = "F:"
strDriveLetter2 = "G:"
strDriveLetter2 = "H:"

strRemotePath1 = "\\SERVER1\Groupshares\Systeembeheer"
strRemotePath2 = "\\SERVER2\Groupshares2\Verkoop"
strRemotePath2 = "\\SERVER1\Groupshares1\Inkoop"

Set objNetwork = WScript.CreateObject("WScript.Network") 

objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
On Error Resume Next
objNetwork.MapNetworkDrive strDriveLetter2, strRemotePath2
On Error Resume Next
objNetwork.MapNetworkDrive strDriveLetter3, strRemotePath3
On Error Resume Next

WScript.Quit

[ Voor 43% gewijzigd door Verwijderd op 14-11-2006 16:38 ]

[BikkelZ]

Inderdaad, dus gewoon onder GPE -> User -> Windows -> Scripts -> Logon aangeven dat een bepaald script gestart moet worden met bepaalde parameters. Het script hoef je zo zelfs niet eens meer te veranderen, het wordt gewoon steeds met verschillende parameters opgestart.

[Verwijderd]

BikkelZ schreef op donderdag 16 november 2006 @ 14:35:
Inderdaad, dus gewoon onder GPE -> User -> Windows -> Scripts -> Logon aangeven dat een bepaald script gestart moet worden met bepaalde parameters. Het script hoef je zo zelfs niet eens meer te veranderen, het wordt gewoon steeds met verschillende parameters opgestart.

En dan bij elke user een ander script.
Geef mij het oude vertrouwde kix-script maar en alles op basis van security groepen.
Printers uitdelen, mappings maken geen probleem.

[BikkelZ]

Alles werkt nu prima (heb er voor gezorgd dat je iets waar je geen rechten toe hebt ook niet kunt zien, en dan iedere group rechten op bepaalde mappen), maar mijn roaming profiles worden niet opgeslagen na een sessie. Ff verder zoeken.

---------

Alles wordt gewoon prima opgehaald, maar bij het wegschrijven treden er problemen op. De map waarin de profieldata van de user staat daar hebben alleen Administrators en de User zelf rechten op.

[ Voor 30% gewijzigd door BikkelZ op 16-11-2006 16:52 ]

[WaSteiL]

Ik heb het volgende script samengesteld wat gewoon vanuit je Default Domain Policy kan draaien. Hoef je geen apart afdelings scripts te maken en die te plaatsen op aparte OU's.

VBScript:

Option Explicit
DIM ObjNetwork, ObjUser, CurrentUser
DIM bForce, bUpdateProfile
DIM strDriveLetter, strGroup

bForce = "True"
bUpdateProfile = "True"
err.number = vbempty

'--------------------------------- CONST BLOK ---------------------------------------------------

' Definieren drive-letters
CONST strDriveLetter1 = "X:"
CONST strDriveLetter2 = "Y:"
CONST strDriveLetter3 = "Z:"


' Definieren UNC-paden
CONST strRemotePath1 = "\\SERVERNAAM\Sales"
CONST strRemotePath2 = "\\SERVERNAAM\Marketing"
CONST strRemotePath3 = "\\SERVERNAAM\Directie"


' Definieren groepsnamen
CONST Sales_Group = "cn=Sales"
CONST Marketing_Group = "cn=Marketing"
CONST Directie_Group = "cn=Directie"


'--------------------------------- CODE BLOK ---------------------------------------------------

SET ObjNetwork = CreateObject("WScript.Network")
SET ObjUser = CreateObject("ADSystemInfo")
SET CurrentUser = GetObject("LDAP://" & objUser.UserName)
strGroup = LCase(Join(CurrentUser.MemberOf))


'Verwijderen alle oude netwerkschijven
On Error Resume Next
objNetwork.RemoveNetworkDrive strDriveLetter1, bForce, bUpdateProfile
objNetwork.RemoveNetworkDrive strDriveLetter2, bForce, bUpdateProfile
objNetwork.RemoveNetworkDrive strDriveLetter3, bForce, bUpdateProfile
On Error Goto 0

' Indien lid van de groep Sales: koppel X: drive
IF InStr(strGroup, Sales_Group) Then
    objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath1
    END IF

' Indien lid van de groep Marketing: koppel X: drive
IF InStr(strGroup, Marketing_Group) Then
    objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath2
    END IF

' Indien lid van de groep Directie: koppel X: drive
IF InStr(strGroup, directie_Group) Then
    objNetwork.MapNetworkDrive strDriveLetter1, strRemotePath3
    END IF

WScript.Quit

[babbelbox]

Je kan volgens mij ook werken met GPO's en daarin dan login scripts definieren.

Loginscript met de net use naar de bewuste share op de server

Het loginscript gebruik je bij de user-settings van de GPO en de GPO koppel je vervolgens aan een groep, waar dan de juiste gebruikers weer lid van zijn

[BikkelZ]

babbelbox schreef op vrijdag 17 november 2006 @ 08:52:
Je kan volgens mij ook werken met GPO's en daarin dan login scripts definieren.

Loginscript met de net use naar de bewuste share op de server

Het loginscript gebruik je bij de user-settings van de GPO en de GPO koppel je vervolgens aan een groep, waar dan de juiste gebruikers weer lid van zijn

Ik zit er nu even niet achter, maar uit mijn hoofd kreeg ik het idee dat een GPO aan een OU te koppelen is maar niet aan een groep, of moet ik er gewoon voor zorgen dat de groep in de OU zit waar de GPO aan gekoppeld zit?

BTW wat betreft dat niet kunnen terugschrijven van het profiel, zou het soms niet helpen om even alle profieldata op de desbetreffende computer weg te gooien, de gebruiker een keer op een andere in te laten loggen en zo een gerefreshed profiel te krijgen?

Ik kan me herinneren dat zulke dingen wel eens leken te helpen.

[WaSteiL]

BikkelZ schreef op vrijdag 17 november 2006 @ 11:35:
[...]


Ik zit er nu even niet achter, maar uit mijn hoofd kreeg ik het idee dat een GPO aan een OU te koppelen is maar niet aan een groep, of moet ik er gewoon voor zorgen dat de groep in de OU zit waar de GPO aan gekoppeld zit?

BTW wat betreft dat niet kunnen terugschrijven van het profiel, zou het soms niet helpen om even alle profieldata op de desbetreffende computer weg te gooien, de gebruiker een keer op een andere in te laten loggen en zo een gerefreshed profiel te krijgen?

Ik kan me herinneren dat zulke dingen wel eens leken te helpen.

Je kan een GPO aan een OU hangen, maar ervoor zorgen dat alleen een bepaalde group de betreffende GPO kan uitvoeren. Dat is handig voor een hoop zaken, maar erg omslachtig voor een logon-script. Sowieso moet je daarvoor alsnog een logon-scripts maken per afdeling en per afdeling ook een GPO.

[Verwijderd]

[b][message=26866607,noline]Het loginscript gebruik je bij de user-settings van de GPO en de GPO koppel je vervolgens aan een groep, waar dan de juiste gebruikers weer lid van zijn

precies!

[Verwijderd]

Verwijderd schreef op donderdag 16 november 2006 @ 14:42:
[...]


En dan bij elke user een ander script.
Geef mij het oude vertrouwde kix-script maar en alles op basis van security groepen.
Printers uitdelen, mappings maken geen probleem.

wat kix er mee te maken heeft ongaat me een beetje. vbs kan net zo goed (zelfs beter) dit regelen.

Wat me aan de ou oplossing opvalt is dat het nogal omslachtig is. GPO koppel je aan een OU en een group geef je rechten op de GPO. De group heeft dan tevens rechten op de share.
Volgens mij is het dus onnodig om de OU te bepalen en de group rechten te geven op de OU, aangezien simelweg overbodig is.

het komt er op neer dat:
- meerdere gpo's aanmaken
- rechten zetten op GPO's

nodig is om de group membership te bepalen, terwijl dat 1 regel vbs code is.