Initializing the root folders to display

Is there a more useful fix for this problem than disconnecting any mapped
drived that are not connected?
I have drives mapped for both work and home use and really don't want to
have to remap my drives every time I change locations.

Unfortunately not if you want the Office programs to start
and work with files and folders quickly. This really became
an issue with the newer versions of Office because Office 97
had no lag time if you had unconnected mapped drives.
Apparently MS changed the way they handled file and folder
information in newer versions of Office.

I have two laptops that I regularly transfer between my work
DNS network and my home peer-to-peer network. I have
created batch files and placed shortcuts to them in the
quick launch toolbar to log-on and log-off to the individual
drives in each network. It's a pain in the butt but it does
work.

A sample of the log-on and log-off batch files are:

Onto the DNS network where there are two servers and two
other computers that are shared peer-to-peer that I
regularly connect to.

cd \windows\system32
NET USE R: \\XXX2\RECORDS /persistent:no
School records on server
NET USE Z: \\XXX2\LVTRAVELCOURSE /persistent:no
Course documents on server
NET USE P: \\XXX2\LVTRAVEL /persistent:no
Personal folder on server
NET USE N: \\XXX1\PROGRAMS /persistent:no
Shared programs on server
NET USE V: \\CDCOPIER\CD\LVTRAVEL /persistent:no
Personal folder on CD/DVD duplicator
NET USE X: \\FACULTY9\C$ /persistent:no
My office computer's system drive
rem NET USE Y: \\FACULTY9\D$ /persistent:no
My office computer's backup drive not normally connected

The "/persistent no" will automatically disconnect network
drive when I shut down the computer. If I hibernate my
laptop instead of shutting down the drive mappings come back
when I turn it on the next morning.

Disconnects the network if I simply hibernate the drive
between work and home.

cd \windows\system32
NET USE R: /delete
NET USE Z: /delete
NET USE P: /delete
NET USE N: /delete
NET USE V: /delete
NET USE X: /delete
NET USE Y: /delete

Log onto home network: I have three Network Attached
Storage devices connected to my wireless router/switch along
with one desktop currently in service along with three
wirelessly connected laptops.

cd \windows\system32
NET USE W: \\BACKUP-250\BACKUP /persistent:no Backup
NAS device - 250 GB
NET USE S: \\Documents\Document /persistent:no
Work drive on NAS - 250 GB
NET USE O: "\\SONY\SONY C" /persistent:no
Home desktop system drive - 60 GB
NET USE P: "\\SONY\SONY D" /persistent:no
Home desktop 1st work drive - 100 GB
NET USE Q: "\\SONY\SONY E" /persistent:no
Home desktop main data drive - 300 GB
NET USE T: \\MOVIESTORE\MS /persistent:no
NAS where all video files stored - 500 GB

I hope voting is not the only reason that microsoft fixes dumb behavior.
This particular behavior is what has switched many of my clients away from
Microsoft and onto Apple. Not only does it stop the owner of the computer
for working with no benefit to them for waiting but they "offer" a cancel key
that seems to indicate I can say, "never mind I don't want to wait" and
instead does nothing at all. The computer that I purchased and the software
that I purchased has no respect for my time. It's a VERY bad idea and, as I
said, I know of some market share loss specifically due to this kind of "take
over the computer" behavior.

I think this is more than an office issue as well. The very same behavior,
unreal slow waits for drop downs, etc. occurs in explorer. I think office is
using explorer code and that is where MS has messed up. In todays connected world there is no excuse for waiting many many seconds on network connections that don't respond quickly, the likelyhood of them responding in 10 or 20 seconds if they do not respond in 1/2 second is so incredibly low that the value of waiting in negative by alot

When disconnecting mapped drives doesn't work

http://support.microsoft.com/kb/821690

Old HP print drivers...I just deleted the printers.

Consider the fact this design behavior has been around for over a
decade. People learning to configure networks and drive mapping properly
prevents undesired outcome.

Having offline mapped drives shouldn't cause this type of critical error. MS didn't trap this error thar occors 100% in their own ecosystem. Shame that they don't fix it.