"especially when your script grows bigger and bigger and bigger and ....... "

This is precisely why I recommended that you don't code site/user/computer logic into your script. The bigger the script, the harder to maintain, and the more opportunities you have for errors.

Using an INI file, you could create something like this:
 Code:
[DECISION-01]
Printers=\\server1\printer1;\\server1\printer2
Default=\\server1\printer2

Now all you do is create a section like that for each "decision point". A "decision point can be a computer, group, OU, site name, or subnet.

Once you have this INI configured, you have some simple code (in this example, a per-computer decision):
 Code:
$SectionID = @WKSTA
$Printers = ReadProfileString('.\printermaps.ini', $SectionID, 'Printers')
For Each $Printer in Split($Printers, ';')
  $ = AddPrinterConnection($Printer)
Next
SetDefaultPrinter(ReadProfileString('.\printermaps.ini', $SectionID, 'Default'))

Now you only update the ini file, not your code, as printers or decision-points change, and your code is short, sweet, and simple.

The code above can be easily adapted to any decision-point by replacing the $SectionID= line with the proper logic. There are UDFs to identify subnets, OU and group membership, and my web site has a UDF that accepts a network IP address, and returns a value from a config file based on the subnet your computer is in. With it, you could create a table of site-names by subnet, returning the SiteName directly to the $SectionID value.

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