We use a combination of methods.
Application Storage:
Like Safado we use AD Group Policy to map drives though we typically use this just for specific application storage. If a user is a member of a specific security group in AD the Group Policy applies and a drive is mapped. Security filtering is used to ensure that the specific Group Policy only applies to members of a certain security group even though the Group Policy itself is linked at the domain level. This is how we get around constraints of the the OU structure not necessarily matching up with who needs the mapped drive. Of course a corresponding Discretionary Access Control List (DACL) is used on the share itself to ensure that only members of the group have access permissions.
User Files:
A single share is created on DCs and read only access to the share is given to all Authenticated Users. Inside of the share a folder is created with the same name as each person's username and the user's account is the only one given access (read, write, execute) to the folder. Access Based Enumeration is turned on for the share and as such other users cannot see the folders of other users regardless of being allowed read access to the main shared folder. The user profile section in AD contains settings to allow a single mapped drive and we use this for user files only. The %username% macro can be used in these boxes and as the macro implies it is replaced with the actual username at login, resulting in a mapped drive with contents specific to that user.
Fault Tolerance:
In the event that the mapped drives need to be a bit more fault tolerant and handle the loss or disconnect of one (or more) DCs you can use DFSR (Distributed File System Replication). For example a DFS Namespace could be created on three DCs and the DFS Namespace UNC path could be used in the Group Policy or AD user profile. This would result in a setup where files are accessible even if a DC goes down and furthermore would allow for the system to act like a CDN if you have DCs in other geographical locations that is a member of the DFS Namespace.
Like Safado said the shares will show up with a red X if they cannot connect just double-clicking on the share once the server is online will allow access.
Note: I couldn't post a link to the MS page for DFSR due to reputation being below 10 :-(
Edit: Linking a ton of GPO objects to the top of the domain level is not exactly a great idea. A well thought out OU structure may allow you to link the drive mapping GPO object to an OU which contains only the users which need to mount the share. In such case there is no need to use the nuance of security filtering as the inheritance structure of your OUs already handles this. Of course this isn't always the case...for example when dealing with a client's AD domain that has been poorly managed :P.