Biscuit,

Welcome!


1. You could use the pre-built login script from my site to do all of this. This script is in use at dozens of sites without code modification.

Simply define the resource records in the config file to map drives and printers. You can control what is mapped by generic privilege (anyone, notguest, admin), group membership, or OU membership. There are complex mapping capabilities - you can require membership in multiple groups; membership in one (set of) group(s) and not other(s); or even map only when the user is NOT a member of a (set of) group(s).

Another powerful feature is path rewriting. This lets you map dozens of different resources to the same place based on user, group, OU, or network subnet. Let's say you have 10 departments and each has a unique share. You decide that each department should map their share to the T: drive. Each department is represented by a distinct OU. You could create 10 resource records based on the OU membership, or, you could create 1 resource record and 10 lookup values using Path Rewriting. The resource path "&OU:Dept&" would be translated to a correct UNC path by looking for the user's OU in the Dept lookup record.

Once basic resource mappings are complete, you can display message files and run commands to customize the user environment, such as using Kent's Outlook profile script. You can Run them asynchronously, Shell them to run synchronously, or even Call other Kix scripts, taking advantage of the built-in variables and UDFs.

2. \\MyDomain\netlogon is probably the quickest/easiest way to push files to the netlogon share across the network, where they will be replicated to other DCs. In SBS, it's unlikely you'd have a second DC, and even if you did, it would be not be of much value.

3. You can't use Startup scripts - those control computer initialization, not user environment initialization. If you're new to login scripting, I'd avoid using GPOs to define them and instead simply define "Kix32.exe" in each user's Login Script profile field, especially in an SBS environment where there's no dedicated admin. Do you really want "Joe's cousin's son" (he has a PC at home...) tinkering with GPOs when you're on vacation? ;\) Been here, done this - SBS+Volunteer=Keep It Simple!

LogIn scripts - defined in the user profile - run in an envoinment where the Netlogon share is the initial directory. This makes things easy to find. LogOn scripts - defined by GPO - need to have full UNC paths defined for everything, and are a bit less forgiving. Also, referencing UNC paths for everything, admins often refer to specific servers - \\server\netlogon - instead of the domain - \\%USERDOMAIN%\netlogon. This practice can wreak havoc when DCs are downed for maintenance or replaced. This is almost the same as Mart's "@ldrive + '\mapdrivesscript.kix'" - I just prefer a system environment var over the macro. $LDRIVE isn't a drive letter as the name implies, but a UNC reference to the Netlogon share on the authenticating DC. It really doesn't matter which you use - "6 of one, half dozen of another" as they say in the Old Country. Just pick one method and use it consistently.

Glenn
_________________________
Actually I am a Rocket Scientist! \:D