Your concept of the common Z: drive opens a number of concerns:
- if you aren't careful applying NTFS security, you can expose data to unauthorized users
- You can run out of space due to the needs of one dept, but affect all depts
are two that immediately come to mind.

Here's what we do at a large environment...
There are 3 file servers. Each has an M: drive of 2G (the smallest we can allocate with the SAN, but smaller is better). This drive has no data, but holds several mounted volumes. The volumes can be local disk or SAN, and each holds a specific type of data. For example, we might create mount points for Finance, Marketing, and User Departments 1-99 on one server.

So - Each of these mounted volumes holds a similar type of data. This way, if NTFS permissions are poorly set, it's less likely to be an issue than if Finance and Users shared a common root. There might be 4 shares in the Finance folder, a dozen in Marketing, and up to 99 in the UserDept1-99 folder. Most of these shares can be defined and secured quickly with Kix and the Net command. Each share is related to an AD OU, in this environment, which makes things easy.

Using my login script, I can use an OU Path Rewrite function, that determines the user's OU, and then uses that to lookup the UNC path to their share. So, when Maria from Dept 47 logs in, the resource for the Z: drive says
 Code:
Target=Z
Path=&OU:DeptShare&

This tells the logic that we want to map something to Z, and we should look at the "DeptShare" section for an entry that says
Dept 47=\\fileserver2\Dept47
That connects that resource to the z: drive for that user. With this, I know that every user will have a Z: drive, it will be unique for each department, and they can't access any other departmental share. Further, Finance, Marketing, and User departments are physically isolated on the servers. This method takes more planning, but the rewards are better security, ability to expand the storage, distribute the storage across multiple servers, and easy customization of a shared drive map.

As for your new printer logic, you're on-track. Keeping each resource separate is better. I'd reverse the logic, though..
 Code:
; repeat this logic for each printer resource...
$Resource = '\\server\printer'
$Map=1 ; allow mapping of this resource
If Not Ingroup(groupX) $Map = 0 EndIf
If Not Ingroup(groupY) $Map = 0 EndIf
If $Map
  AddPrinterConnection($Resource)
EndIf

Thus, you assume that you DO want to map the resouce, and find ways not to - not in group, not in OU, not at correct AD site, etc.. This way, you only have one resource to define, and one line to map it on.

I'm STILL NOT a fan of placing data in the script, but it will get you started. Of course, you could just download the login script... ;\)

Glenn

PS - maybe next time you could ask a complex question that has a simple answer? ;\) \:D
_________________________
Actually I am a Rocket Scientist! \:D