Office programs slow after huge server changing project

Question

Hello All!
Long story: A while back, my team has started and finished a migration of several different smaller domains, to one main domain.
A lot of servers were either re-purposed or decommissioned, the migration was a success.
Now a few days later our service desk has received an increasing amount of tickets about people who have issues with the time it takes opening files in excel, word, etc.
Anyway, in the past many locations were mapping drives based on logonscripts for example, in some cases including a part where all drives (and printers) got disconnected first and then only those ones got added which were really needed. This was “easy” as
“local admins” knew the drives which were needed and which not.
Naturally, you can do the same with the help of group policies, but the problem in this very global world is the fact we cannot “disconnect in a centralized way”, as we might disconnect “manually per user mapped drives” and this might cause a lot of gray hair
for many people. In the long run people tend to forget what they mapped themselves, so in case of any issues the request is only to “reconnect my H: drive which got lost because you disconnected it”.
The point of this whole message is the fact we have now realized the following “phenomena” has taken place in multiple locations:
-    user has mapped drives in use, M:\, R:\, S:\ and so on, pointing to multiple local/global servers and shares
-    server migration or other server side changes takes place
-    FQDN for the server changes, or UNC path for the target location changes
-    user’s workstation/laptop side drive mappings (AND PRINTERS) are still trying to get connected with the old nowadays not-existing target
Servers were 2003, are now 2008 R2.
Workstations consist of only Windows 7 machines.
Short question: Is there a tool or script available which would help us to remap network drives en mass, without GPO, or to see which drives are orphaned drives?
Many thanks for reading my loooong post.

Answer 1

Do yourself a big favor that you should have done before migrating.  Move all shares onto a DFSR share and use GP to map all required drives.
Now that you have done it the hard way I recommend usijng a logon script to dump lists of mapped drives then decide which should be mapped via GP and which should not or should be left to the user.
There is no easy answer or tool which is why  almost all migration documents suggest fixing this before the migration.
Start by dumping the session drives in a logon script.
NET USE > c:\temp\drives.txt
¯\_(ツ)_/¯