Originally Posted By: Howard Bullock
Without asking additional questions, I have a concern about only relying on logon server as the way of determining what building the computer is located.

I have seen some instances where the expected authentication server was not the actual logon server. This would lead to extremely slow performance as the drives would be mapped to the wrong building.


Good point, but wouldn't that indicate an issue with AD configuration or the authenticating server?

If the former then it should be fixed in the configuration, not the mapping script.

If the latter, then you probably *want* the drives to be mapped to a non-local server, as there is a problem with the local server. There is not much point in attempting to force the mapping to a local server based on IP address if it is down.

If the buildings are all set up the same way then you can reduce the code to a generic form:

 Code:
;Remove all drive mappings so we dont have an old one
USE * /DELETE
 
$sSite=Split(@LServer,"-")[0]
USE G: $sSite+'-fs1\apps'
USE I: $sSite+'-fs1\installs'
USE R: $sSite+'-fs1\resources'
USE T: $sSite+'-fs1\ttl_net'
USE M: $sSite+'-fs2\smecourses'
USE S: $sSite+'-fs2\sme'