Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Please post useful commands that you use in your logon script.

Here are some that I use:

map a network drive:
net use v: \fileserver\apps
map a network printer:
RunDll32.EXE printui.dll,PrintUIEntry /in /n "\\printserver\Xerox DC1100 PCL"
delete a network printer:
RunDll32.EXE printui.dll,PrintUIEntry /dn /q /n "\\printserver\HP LaserJet 2300"
disable windows firewall:
netsh firewall set opmode disable
install a new program:
if not exist "C:\Program Files\Antivirus\" "V:\Antivirus\install.msi"
create a shortcut on users Desktop:
copy "V:\shortcuts\dictionary.lnk" "%USERPROFILE%\Desktop"

share|improve this question
5  
Eww... installing software from logon scripts, or disabling Windows Firewall, implies that your users have "Administrator" rights. Shame on you. –  Evan Anderson Jun 4 '09 at 17:41
    
This question has no 'answer' - should probably be a wiki. –  Kara Marfia Jun 4 '09 at 19:34
    
changed to community wiki. Evan Anderson: It's just an example,only very few people have admin rights and different logon script for some reasons. –  onesysadmin Jun 4 '09 at 23:53
add comment

7 Answers

up vote 5 down vote accepted

I might get down voted for this, but so be it. I've always considered logon scripts to be kind of hack'ish and try to only use them as a last resort. There are so many ways to manage systems and users these days with things like Group Policy, Group Policy Preferences, and SCCM/SMS. I mean, there's always going to be cases where there just isn't a better way to do things. But many of the examples provided so far can easily be done without a login script like installing software and mapping network drives.

share|improve this answer
    
Makes sense. I think there are A LOT of admins who feel the same and I can understand that. I love logon scripts for some reason, but most of my partners share your view. –  cop1152 Jun 4 '09 at 19:51
add comment

Here's one of my favorites. We've got 700+ users and various divisions and subgroups that require their own drives. We're mapping based on username currently:

if %username% == [username] net use /delete Z:\
if %username% == [username] net use Z: \servername\share

another is the mapping of homedrives:

net use H: \homeserver\%username% /persistent:yes

share|improve this answer
1  
+1 because I will be using this from now on –  cop1152 Jun 4 '09 at 18:06
add comment

For drive mappings we actually use vbscript (actually we use .vbs instead of .bat files regardless for login scripts):

Set WshNetwork = CreateObject("WScript.Network") WshNetwork.MapNetworkDrive "H:", "\fwmnas\qip"

I also have part of it necessary to determine whether the OS is x86 or x64 based:

'Determine if OS is 32 bit or 64 bit first

Set WshShell = WScript.CreateObject("WScript.Shell") X = WshShell.RegRead("HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\PROCESSOR_ARCHITECTURE") If X = "x86" Then

That's very basic but basically you have an IF THEN ELSE part that says if it is 32 bit do this otherwise do this...I just left out the rest of the code. If you are interested in more of it let me know.

share|improve this answer
add comment

I've already documented my kix login script which does pretty much the same things as you are requiring here: http://thisishelpful.com/kix-login-script-map-printers-network-drives-setting.html.

Take a look at it and let me know if you have any other requirements. I've personally found that KIX is really easy to understand and for a System Administrator who has never seen KIX scripting language before, you'll find it very easy and straight forward when you view the commands.

share|improve this answer
add comment

The IFMEMBER.EXE utility is old, but works with all versions of Windows through 7, and is extremely useful for conditional scripting based on AD group membership.

IFMEMBER Marketing | net use m: \\\server\marketingshare

or

IFMEMBER TestUsers | cmd /c t:\scripts\runsomescript.cmd

link: http://www.microsoft.com/download/en/details.aspx?id=7895

share|improve this answer
1  
You can also just set the permissions on "t:\scripts\runsomescript.cmd" to only allow members of the appropriate group access to execute the script and then just "CALL" it from your "main" script. Users without rights to execute it will just skip on past it. –  Evan Anderson Nov 14 '12 at 18:45
add comment

Maybe there's a better way to do this by now, but I've got a policy applying only to my server OU that runs bginfo.exe with parameters: %logonserver%\netlogon\bginfo\server.bgi /timer:0

It throws a few choice bits up as the background, to make remote sessions easier to identify.

share|improve this answer
add comment

This is from a long time ago, but if you're not using DFS or something similar you might find some use for this (if you have identical scripts running in different locations to ensure files are run or copied from the correct local servers):

Dim WSHShell,strRegKey, DFS, DCName

Set WSHShell = WScript.CreateObject("WScript.Shell") 
strRegKey="HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History\DCName" 
DCName = lcase(WSHShell.RegRead(strRegKey))

If DCName = "\\NADC01.domain.com" or DCName = "\\NADC02.domain.com" then
    DFS = "NAsite"
ElseIf  DCName = "\\UKDC01.domain.com" or DCName = "\\UKDC02.domain.com" then
    DFS = "UKsite"
Else
    DFS = "anotherSite"
End If

WshShell.Run("\\domain\" & DFS & "\DfsRoot\share\script.cmd")
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.