Server weg met loginscript

[Dromer]

Hier op het bedrijf hebben we te maken met de volgende situatie.
Onze meest gebruikte server is vervangen en heeft een andere naam gekregen.
Nu wil ik via het loginscript alle verbindingen die de gebruikers zelf naar die server hebben opgezet "wissen".
Enig idee welk commando ik daarvoor kan gebruiken.
Alle mappings wissen is geen optie aangezien er meerdere mappings naar meerdere servers lopen die niet in het loginscript zitten.
Ik wil dus ook echt alleen de mappings naar die ene server eruit.
Server is nt4.
+-200 werkstations met Win2000 en Win95.

[killah]

Wat dacht je van zo'n commando ?

net use g: /delete

[voodoo202]

Als het de meest gebruikte server is, Waarom verander je dan de naam. Je had hem toch ook eerst kunnen installeren, dan testen met 3 pc's ofzo, en als hij werkt, dan online brengen.

Dan heb je toch ook geen problemen met netwerkdrives enz.

[Dromer]

Het probleem is dat het niet schijf gebonden is.
De afdelingen hebben vaak zelf ook een mapping gemaakt naar de server waar wij de schijfletter niet van weten.

Dat de naam van de server veranderd is komt omdat we een wereldwijd netwerk hebben en de naamgeving conform dat netwerk moest worden.

[seq_uence]

Kun je niet iets doen met hostname resolving, dus in een hosts file het IP van de nieuwe server zetten met de naam van de oude server ofzo ?

Ik doe maar een gok hoor dus niet gelijk schieten.

[DigiK-oz]

Op dinsdag 02 juli 2002 10:22 schreef Dromer het volgende:
Het probleem is dat het niet schijf gebonden is.
De afdelingen hebben vaak zelf ook een mapping gemaakt naar de server waar wij de schijfletter niet van weten.

NET USE \\OUDE_SERVER\SHARENAAM /DELETE dan misschien ? Mogelijk krijg je echter een probleem met de 'timing' van je loginscript, als de shares er nog niet zijn omdat de desktop er nog niet is...Give it a try.

Andere optie misschien met kixtart o.i.d remote de registry van de workstations (local_user\network\) afzoeken naar de server, en indien gevonden betreffende driveletter-key deleten.

[voodoo202]

Dan zorg er je toch voor dat je ouder computer naam wordt geroute naar de nieuwe server.

Maar als het een wereldwijd netwerk is. Komt er dan niet iemand van het bedrijf die die server installeert. Of ben jij die iemand.

[Verwijderd]

Het volgende NT script lost alles voor je op. Deze kun je bijvoorbeeld in je login-script verwerken.

suc6

code:

@echo off
REM Disconnect some connections. Can be used in a logon-script

echo.
echo.

REM Create a VAR with (partial) server names and/or shares to
REM disconnect
REM "\\WEBSERV" will disconnect all connections which contains
REM that name,
REM for example : \\WEBSERV\NETLOGON or \\WEBSERVER01\ShareName
REM.
SET NOCON=\\WEBSERV \\SERVER02 \\SERVER03\C$
SET TMPFILE=%TEMP%\disconn.txt

REM Use FINDSTR to match the search var with the 
REM existing persistant connections
REM and save the result to a temp file
net use | findstr /i "%NOCON%" > %TMPFILE%

REM process the temp file and disconnect drives
REM fancy way....
for /f "tokens=2,3" %%i in (%tmpfile%) do call :process %%i %%j

REM quickest way....
REM for /f "tokens=2" %%i in (%tmpfile%) do NET USE %%i /D >NUL

goto end

:process
REM Only needed for the fancy way....;-))
echo disconnecting drive %1 from %2
net use %1 /d >NUL
goto :eof

:end

[Dromer]

Thx BCS
Dit lijkt inderdaad te gaan werken

[Verwijderd]

Youre welcome, goed te horen dat het opgelost is

[seq_uence]

Op dinsdag 02 juli 2002 11:37 schreef Dromer het volgende:
Thx BCS
Dit lijkt inderdaad te gaan werken

Je gaf aan dat de afdelingen zelf ook mappings hebben gemaakt waarvan je de schijfletter niet weet, dat los je volgens mij niet op met dat script....

[Verwijderd]

Op woensdag 03 juli 2002 09:15 schreef seq_uence het volgende:

[..]

Je gaf aan dat de afdelingen zelf ook mappings hebben gemaakt waarvan je de schijfletter niet weet, dat los je volgens mij niet op met dat script....

Echt wel, want de drive letters zijn helemaal niet interessant op voorhand. Het enige wat het script behoeft zijn de servernamen met of zonder share of delen hiervan. Dat bepaal je zelf in de NOCON variable

ff voor de duidelijkheid, persistant connections die door een user zijn aangemaakt worden altijd eerst gemapped voordat het logon-script gaat lopen. In het logon-script is dus alle informatie bekend om het bovenstaande uit te kunnen voeren.

[Dromer]

Het werkt inderdaad hoor.
Alleen de win95 pc's hebben er moeite mee maar daar verzinnen we wel wat anders voor

[Verwijderd]

Ik zou toch maar je netwerk beter gaan documenteren als ik jou was en alle mappings in logonscripts zetten.

[Arno]

Op vrijdag 05 juli 2002 20:45 schreef VipTweak het volgende:
Ik zou toch maar je netwerk beter gaan documenteren als ik jou was en alle mappings in logonscripts zetten.

Dan hou je nog niet tegen dat eigenwijze users zelf mappings bijmaken, behalve als je dat in een GPO eruit sloopt

[Verwijderd]

Op vrijdag 05 juli 2002 21:19 schreef Traag het volgende:

[..]

Dan hou je nog niet tegen dat eigenwijze users zelf mappings bijmaken, behalve als je dat in een GPO eruit sloopt

Bijvoorbeeld, gewoon policies gebruiken.
Natuurlijk wel rekening houden met hun wensen bij het mappen

[Verwijderd]

Op vrijdag 05 juli 2002 22:58 schreef VipTweak het volgende:

[..]

Bijvoorbeeld, gewoon policies gebruiken.
Natuurlijk wel rekening houden met hun wensen bij het mappen

Gewoon in je logon-scripts rekening houden met de mogelijkheid dat je gebruikers een aangepast script willen hebben, bijvoorbeeld 1 met een duidelijk naam, die men in hum home directory kan plaatsen en dus kan aanpassen. Wat daar dan in gebeurt is verantwoordelijkheid van de gebruiker.

[Verwijderd]

Op vrijdag 05 juli 2002 23:13 schreef bcs het volgende:

[..]

Gewoon in je logon-scripts rekening houden met de mogelijkheid dat je gebruikers een aangepast script willen hebben, bijvoorbeeld 1 met een duidelijk naam, die men in hum home directory kan plaatsen en dus kan aanpassen. Wat daar dan in gebeurt is verantwoordelijkheid van de gebruiker.

Homedirectory zet je niet in je loginscript

[Verwijderd]

Op zaterdag 06 juli 2002 00:40 schreef VipTweak het volgende:

[..]

Homedirectory zet je niet in je loginscript

Klopt, maar je mist denk ik wat ik bedoel;
eg: Een connectie met de home-dir is al gemaakt. Het logon-script van het domein loopt inmiddels. Om nu het een en ander makkelijker te maken voor de gebruikers, hou je aan het eind van het logon-script een controle of bv "myconn.cmd" bestaat in de home-dir van de gebruiker, en die start je dan ook op met een call daar naar toe.
Zo kan de gebruiker zelf zijn extra mappings bijhouden...

[squaddie]

Bij mijn vorige werkgever (stage) waren alle mappings via het loginscript geregeld. Ter info het is gemaakt met Kixtart.

Onderstaande script is het "site-script" (niet het orginele bedrijfsscript maar een erop gebaseerd (vereenvoudigd) scriptje, kan dus netter/beter ) werkt met de volgende voorwaarden.

- Vast model loginnaam, IDABC123 = eerste 2 letters staan vast, volgende 3 is site indentificatie en een volgnr.
- Speciale login groepen (begint met een X), gebruiker A werkt op controlling maar moet ook bij sales kunnen. Resultaat gebruker wordt toegevoegd aan de speciale controlling groep en bij de normale sales groep.
- gebruikers mogen geen eigen mappings maken en deze worden bij het inloggen ook verwijderd.

In theorie drie lagen van scripts, door virusscanner-check, enz zijn een aantal extra scripts bijgekomen.
domainscript <- tijd synchronisatie, virusscanner check, etc.
|
V
sitescript <- site afhankelijk.
|
V
userscript <- alleen indien er speciale mappings nodig zijn

code:

;---------------------------------------
; declarations 
;---------------------------------------

$srv  = "siteserver"

;---------------------------------------
; start script
;---------------------------------------

color w/b
cls
GOSUB welcome
GOSUB mapping
GOSUB mail
color n/n
exit 1

[knip]
Welkomsverhaal niet relevant.
[/knip]

;---------------------------------------
; drive mapping
;---------------------------------------

:mapping
? "Connecting to server(s)..."
? " "

use * /delete
IF INGROUP("domain users")
    use p: "\\$srv\pttgids"
    use i: "\\$srv\public"
endif
IF INGROUP("xcontrolling")
    use g: "\\$srv\control"
    use h: "\\$srv\bhouding"
endif
IF INGROUP("xsales")
    use g: "\\$srv\sales"
endif

use u: "\\$srv\@userid"

IF EXIST (@LDrive + "\" @userid ".kix")
    CALL @userid ".kix"
endif

return

[knip]
Mailverhaal niet relevant.
[/knip]

Voor de mensen die geen/weinig ervaring hebben met Kixstart een toelichting op het script.
* Alles met een ; is commentaar, wordt door Kixtart genegeerd.
* Regels beginnend met ? is tekst op beeldscherm.
- Declareren van een variable, handig als de server van naam veranderd, in 1x alle servernamen aanpassen
- Start script, met daarin verwijzigen naar de echte scripts, dit handig indien een onderdeel niet werkt met 1 ; is dat hele gedeelte uitgeschakeld.
- Wissen van alle mappings.
- algemene site mapping(s) maken.
- groepmapping(s) maken.
- gebruikers-mapping maken.
- controle op het bestaan van user-script en indien bestaand aanroep usersscript.

IMHO de voor en nadelen van zo'n script.
Voordelen:
- Vraagt weinig onderhoud.
- Nieuwe site toevoegen is bijna kinderwerk (een bestaand sitescript kopieren, nieuwe sitescript en domainscript aanpassen).

Nadelen:
- Het opbouwen van de scripts niet eenvoudig, door bijvoorbeeld een virusscanner-check eventueel gecombineerd met unattended installatie en/of updates van de virusscanner.
- Grote aanpassingen zijn erg arbeidsintensief.

[Verwijderd]

>MHO de voor en nadelen van zo'n script.
>Voordelen:
>- Vraagt weinig onderhoud.
>- Nieuwe site toevoegen is bijna kinderwerk (een bestaand >sitescript kopieren, nieuwe sitescript en domainscript >aanpassen).
>
>Nadelen:
>- Het opbouwen van de scripts niet eenvoudig, door >bijvoorbeeld een virusscanner-check eventueel gecombineerd >met unattended installatie en/of updates van de >virusscanner.
>- Grote aanpassingen zijn erg arbeidsintensief.

Om onafhankelijk te zijn wat betreft de site en logon server kan ook een variable logonserver gebruikt worden in de usermanager. %logonserver%\netlogon\..script..

Wat mij in de probleem stelling van Dromer opvalt is dat gebruikers zo veel vrijheid krijgen. Waarom moet een gebruiker een mapping kunnen maken? de shares op de server worden toch door de beheerders aangemaakt voor gebruikt te worden in een logon script.

grx
R

[Dromer]

[b]Op zondag 07 juli 2002 09:21 schreef Joulupukki Wat mij in de probleem stelling van Dromer opvalt is dat gebruikers zo veel vrijheid krijgen. Waarom moet een gebruiker een mapping kunnen maken? de shares op de server worden toch door de beheerders aangemaakt voor gebruikt te worden in een logon script.
grx
R

Heb je helemaal gelijk in.
Ik verbaas me daar ook altijd over bij dat bedrijf.
Ik loop daar voor een migratie van NT4 naar Win2000.
Toen ik de zooi daar dus aan de gang had en gewoon policies wilde instellen begonnen ze gelijk dat de gebruikers veel mogen.
Ze mogen niet hun achtergrond veranderen ivm sexplaatjes maar ze mogen wel zelf een sexspel via de cdrom installeren.
Beetje wazig dus, maar zo is de policy daar.

[squaddie]

Op zondag 07 juli 2002 09:21 schreef Joulupukki het volgende:
>MHO de voor en nadelen van zo'n script.
>Voordelen:
>- Vraagt weinig onderhoud.
>- Nieuwe site toevoegen is bijna kinderwerk (een bestaand >sitescript kopieren, nieuwe sitescript en domainscript >aanpassen).
>
>Nadelen:
>- Het opbouwen van de scripts niet eenvoudig, door >bijvoorbeeld een virusscanner-check eventueel gecombineerd >met unattended installatie en/of updates van de >virusscanner.
>- Grote aanpassingen zijn erg arbeidsintensief.

Om onafhankelijk te zijn wat betreft de site en logon server kan ook een variable logonserver gebruikt worden in de usermanager. %logonserver%\netlogon\..script..

Dat is niet nodig want gebruikers loggen in op een "gebruikers"-domein en voor dit domein is op alle sites een server neergezet.

De servers met de printers, gebruikers- en afdelingdata hangen in een sitedomein.

Hierdoor kunnen gebruikers op alle sites inloggen ongeacht wat hun standplaats is en toch krijgen ze de standaard mappings. Ander voordeel is dat het inloggen bijna (afhankelijk van de drukte op de vaste lijnen tussen sites) net zo snel is als op de standplaats.

Mocht een gebruiker dus tijdelijk op een andere site gaan werken ivm bijvoorbeeld een project, dan moet de ITsupport-afdeling twee dingen te regelen:
- rechten (worden schriftelijk aangevraagd door leidinggevende van project/afdeling).
- evt extra mapping(s) naar siteserver.