Windows Scripting:Where to begin?

Uncle Toxie

Uncle Toxie

Gawd
Joined
Aug 22, 2004
Messages
513
As some of you may know I have recently found myself as the network admin for a small company. So far things are going well but I have grown tired of having to go from workstation to workstation mapping out drives when something changes et all.

The point is that I would love to look into scripting but I am not sure where to start. I am no programer by any means and have managed to forget just about anything I learned in VB6. I still have a grasp on some basic fundamentals (I think I do anyway).

Any pointers from the network gurus? As always, thanks for your help.
 
Mapping drives with a logon script is pretty easy, let me dig up one of the scripts from our PDC. BRB
 
Logon scripts should go in the \\domain\sysvol\domain\scripts\ folder on your PDC.

Open notepad and put something like this in it, and save it as a .vbs to that folder:

rem Sets a drive mapping to the user directory where general lab materials are found
On Error Resume Next
dim Net
Set Net=CreateObject("Wscript.Network")
Net.MapNetworkDrive "I:", "\\servername\Intranet", False
Net.MapNetworkDrive "L:", "\\servername\Volume 1", False
Net.MapNetworkDrive "P:", "\\servername\Program Staff", False
Net.MapNetworkDrive "S:", "\\servername\SEDcare", False
Net.MapNetworkDrive "J:", "\\servername\DataBases", False

Then go into your MMC and browse to where you manage your users, right click a user, click properties, go to the profile tab, and put the name of the script in the field where it says Logon Script.

Voila! It should work, sometimes you gotta logoff/logon a couple times or reboot to get it to initially work.
 
Aslander said:
Voila! It should work, sometimes you gotta logoff/logon a couple times or reboot to get it to initially work.
Click to expand...
You can take care of this problem in the script. Here's is one that I have written that always works.
Code: 
Set objNetwork = WScript.CreateObject("WScript.Network")
Set objShell = WScript.CreateObject("WScript.Shell")

strUser = ""
While strUser = ""
	strUser = objNetwork.UserName
Wend

Sub subMapDrive(strDrive,strShare)  
	On Error Resume Next
	objNetwork.MapNetworkDrive strDrive, strShare
	If Err.Number <> 0 Then
		objNetwork.RemoveNetworkDrive strDrive
		objNetwork.MapNetworkDrive strDrive, strShare
		Err.Clear
	End If
	On Error GoTo 0
End Sub

subMapDrive("U","\\Server\User\" & strUser & "$")
That's used to map a user drive. But, the subroutine "subMapDrive" could be called to map anything.
 
Try Kix32. I use it for my user login script at work. It is much easier than vbscript and does most anything you need for a basic login script.

For example

if InGroup (groupname here)
net use x: \\servername\sharename
endif

That way you can control what drives are mapped by AD group membership or other attributes. This is just very basic functionality, there are a ton more things you can do. Between group policy and kix scripts for login there isn't much else I need.
 
Correct me if I'm wrong...but couldnt group policy combined with good ol'

net use *drive letter* /delete
net use *drive letter* \\unc-path

in batch files achieve the same thing?
 
dx2 said:
Correct me if I'm wrong...but couldnt group policy combined with good ol'

net use *drive letter* /delete
net use *drive letter* \\unc-path

in batch files achieve the same thing?
Click to expand...
Using "net use" creates a persistant mapping. Using a script does not. Persistant mappings can be a pain if you want to change it later. Also, you can do a lot more with a script like map a drive based on Active Directory group membership.
 
MorfiusX said:
Using "net use" creates a persistant mapping. Using a script does not. Persistant mappings can be a pain if you want to change it later. Also, you can do a lot more with a script like map a drive based on Active Directory group membership.
Click to expand...

"net use" only makes persistent mappings if you use the "/persistent" switch.
 
nessus said:
"net use" only makes persistent mappings if you use the "/persistent" switch.
Click to expand...
I have still had the same problem on three different networks with out using that switch. I am just speaking from experience.
 
I haven't seen it mentioned...we're assuming...but is there a "server" on this network...a domain controller?
 
YeOldeStonecat said:
I haven't seen it mentioned...we're assuming...but is there a "server" on this network...a domain controller?
Click to expand...

Indeed, I am in the middle of a complete redesign so I want to try and patch up a lot of the little things that I noticed. Basicly the list so far is, restrict local logon to workstations, prevent users from being able to disconnect and remap network drives and printers, and restrict the software users can install.

Since this is my first honest to (insert diety of your choice here) admin job I am looking at different options to get that done. I figure, even if scripting is not able to accomplish any of the things that I want, it is still a good skill to have.
 
So if a server...there ya go...set the drive mapped in the users account properties. I even still use the old fashioned .bat files...in the netlogon directory of the server.
 
Uncle Toxie said:
Basicly the list so far is, restrict local logon to workstations, prevent users from being able to disconnect and remap network drives and printers, and restrict the software users can install.
Click to expand...
From experience, disabling the ability to map/unmap drives and connect/disconnect printers causes more problems than they solve. If you are trying to troublshoot something, it becomes very difficult. The security permisions on the object/share should takes care of what people are allowed to connect to.

As far as the software installation: They should not be allowed to install anything. This means do not let them run as an administrator.

As far as the log on locally: Only the default accounts should exist. Every user account should be a domain account. You don't want to disable log on locally completely. You still want the administrator account to have access for troubleshooting.

Just my 2 cents. Hope it helps.
 
Wouldn't logon scripts as simple .bats combined with a properly implemented DFS make mapping drives by user and group relatively simple, even if servers where to change around and network paths change?

net use *drive letter* /delete makes sure the same map is implemented each time for a certain mapping....so if a user ever figures out how to disconnect a drive they become reconnected at next logon.
 
dx2 said:
Wouldn't logon scripts as simple .bats combined with a properly implemented DFS make mapping drives by user and group relatively simple, even if servers where to change around and network paths change?

net use *drive letter* /delete makes sure the same map is implemented each time for a certain mapping....so if a user ever figures out how to disconnect a drive they become reconnected at next logon.
Click to expand...
For basic mappings, yes batch files would work. To do anything "advanced" like mapping a drive based on group membership, you are going to need VB Script. I guess I am jsut used to writing scripts so I don't use batch files. There is so much more that you can do with a script.
 
MorfiusX said:
For basic mappings, yes batch files would work. To do anything "advanced" like mapping a drive based on group membership, you are going to need VB Script.
Click to expand...

On Win XP clients does a VB script interpreter/engine need to be deployed? or are the VBS files interpreted on a basic XP install?
 
All versions of Windows have the Windows Script Host. Windows XP has version 5.6. Windows 2000 has 5.1, and I can't remember which version Windows 98 has. Windows 98 and 2000 can be updated to 5.6 which I would recommend. A script is a text file. When you execute it will be excuted using the script host just like a Word file opened with Word.

There a number of different ways to get them to execute, but group policies are what I prefer to use.
 
How would you go about using the GPMC to implement a VBS logon script? On a computer or user level?

I've toyed around with group policy a little, but I'm not to sure on how to get a VBS to run.
 
You can assign startup/shutdown scripts to a computer and logon/logoff scripts to a user.

After you have created a script, in a group policy, you can assign it under User/Computer Configuration > Windows Settings > Scripts. All you have to is add the .vbs to one of the give areas.

The following is a little old, but it will work the same whether you are using the old group policy interface or GPMC:
http://www.serverwatch.com/tutorials/article.php/1474241
 
dx2 said:
Wouldn't logon scripts as simple .bats combined with a properly implemented DFS make mapping drives by user and group relatively simple, even if servers where to change around and network paths change?

net use *drive letter* /delete makes sure the same map is implemented each time for a certain mapping....so if a user ever figures out how to disconnect a drive they become reconnected at next logon.
Click to expand...

Sure, the best way to do it is something like:

Code: 
For i = 0 to colNetDrives.count-1 step 2
wshNetwork.RemoveNetworkDrive colNetDrives.Item(i), bForce, bUpdateProfile			
Next

That way you start with a clean slate each login, and can be sure the mappings are done the same on all clients.
 
pigster said:
Sure, the best way to do it is something like:

Code: 
For i = 0 to colNetDrives.count-1 step 2
wshNetwork.RemoveNetworkDrive colNetDrives.Item(i), bForce, bUpdateProfile			
Next

That way you start with a clean slate each login, and can be sure the mappings are done the same on all clients.
Click to expand...
You can use "net use * /delete" in a batch file as well.
 
I was able to make a logon script to map the network drives and the printer, do you all think that I need to make a logoff script to clear them out? Will it cause an issue if I don't?

I decided to take your advice MorfiusX and skipped restricting the mapping. As long as they can log on and off and be back to normal then the boss is good with that. If the boss is happy, I'm happy.
 
You must log in or register to reply here.
Back
Top