"Server Execution Failed": Bug or Feature?

I seem to have hit a certain flavor of this twice in the past 3 days and
it smells like a bug in 7 to me.

I have "MyDocuments" relocated to a share on a NAS box.

When that folder gets clobbered or the NAS box becomes unavailable,
Windows 7 starts throwing "Server Execution Failed" every time I try to
open any folder any where.

Having provoked it twice myself, I think this is replicable.

Am I the only one?
--
Pete Cresswell

(PeteCresswell) wrote:

I seem to have hit a certain flavor of this twice in the past 3 days and
it smells like a bug in 7 to me.

I have "MyDocuments" relocated to a share on a NAS box.

When that folder gets clobbered or the NAS box becomes unavailable,
Windows 7 starts throwing "Server Execution Failed" every time I try to
open any folder any where.

Having provoked it twice myself, I think this is replicable.

Am I the only one?

How did you change the path to your My Documents folder? Did you
right-click on the old (default) one, select Properties, and under the
Location tab click Move to change the path?

So, in the past 3 days, has that been when your NAS box has been
clobbered or otherwise unavailable? This error occurs when the shell
(aka profile) folders are incorrectly defined in the registry or they
are missing. Since the remote host is inaccessible, the profile folders
are missing. After relocating the profile folder, did you also check
the Indexing service definition on My Documents was also changed? The
way you likely relocated change the path to the profile folder so
anything else that uses the old path has to get updated to use the new
path (and, as noted below, some programs ignore the relocation).
Changing the path for a special folder, especially to a non-local
target, is not a trivial decision, and putting them across a network
means flaky operation (more than having them local) since there's a lot
more dependency of more stuff all working right.

Are you specifying a UNC at the time you want to access the network
drive? Or did you create mapped network drive (i.e., it gets assigned a
drive letter)? If you mapped the network drive (shared it), did you
configure its properties to always reconnect?

Look at Windows Explorer. No matter what folder to where you navigate,
the top portion of WE shows the special folders, like My Documents.
Each time you navigate somewhere in WE, it refreshes. With a mapped
drive, each refresh means WE tries to reconnect to the mapped drive.
Since you moved the special folder off the local drive and onto a remote
drive, and since that remote drive is inaccessible, an error results.

Sysadmins have been encountering this problem for awhile. For example,
laptop users whose shell folders (My Documents, Pictures, Music, Videos,
etc) work fine when they are connected to the domain but get this error
when they're home (and don't connect to the corporate domain, say, via
VPN). The problem arises because you're mapping to a remote drive
instead of using a UNC path to it at the time you (or a program) needs
to access that remote path.

Instead of using static drive mappings, redirect access to the profile
folders to UNC paths. From what I've read (I've not had to do this
since I don't bother to relocate my profile folders), you go into the
group policy editor to redirect access to the profile folders to UNC
paths (and don't use mapped drives). That is, instead of trying to use,
say, a mapped drive R: where you told Windows to relocate a profile
folder, instead you use \\server\user\Documents (or whatever path you
want). Then that remote host is only accessed if and when the folder
under there is accessed. The Home editions of Win7 don't have a group
policy editor (gpedit.msc); however, all policies are registry entries
so you could add policies using the registry editor but only if you know
where and what to add.

If you need access to the files when the remote host (server) is
unavailable, enable offline files synchro- nization (Sync Center in
Control Panel, Manage offline files). The Home editions do not support
offline files (Pro or Ultimate are required). You didn't say which
edition of Win7 you are using.

Rather than relocate your profile folders to a remote path, why not
leave them where they are and use a sync tool to keep it synchronized to
a remote folder? I've not use the Sync Center in Windows 7 but I have
used SyncBack (http://www.2brightsparks.com/downloa...backfree.html).
I don't know if Microsoft's old Sync Toy will run on Windows 7 but there
are lots of these sync tools around. I haven't used SyncBack for awhile
and it would only resolve your problem if you can specify a UNC path to
sync to a local folder (so you're not stuck with using static drive
mappings that cause the error you mention when the remote host is
inaccessible). A couple FAQs at SyncBack's site indicate it supports
UNC paths. Of course, this synchronization means having multiple copies
of the same files, one at each endpoint in the sync. For really large
files, like videos, it could a long time to complete the sync. Of
course, huge remoted files are going to take longer to access, too, and
subject to interruptions in network access along with it getting busy
with other traffic.

If you relocate your documents to a remote path, obviously you can't get
at those documents when the remote host is inaccessible. That's not
only when the remote host is down but when its networking isn't working,
something in the network interferres with reaching that host, firewall
problems, router/switch problems, etc. Seems it would be smarter to
keep local the documents and sync a copy of them to somewhere else.

To be honest, I'm not sure Microsoft intended the shell (aka profile)
folders to get moved to a non-local or non-permanent mass storage
device. The relocates I've seen are to local and non-removable media
(i.e., HDDs or SSDs), not to removable media (USB-attached drives,
rewritable optical discs) or mapped drives or UNC paths. Even users in
a corporate domain will lose their roaming profile and access to their
docs if they cannot login to the domain controller (and have to login
using a local account, if they have one).

Also, some programs do not use the registry-specified path for the
profile folders. They blindly use the default path for whatever it is
under the Windows version under which the program is executed. They
ignore that you moved the profile folder to elsewhere. While keeping
the profiles on local drives, it's better to use NTFS junction points to
relocate them. Then even a program that blindly uses the default path
will still use the redirection path. NTFS junction points are not
usable with network hosts as the target must be a local drive (i.e.,
within the local file system in which the redirection is defined). So,
for example, you could use a junction point to my a profile folder off
of local drive C: to local drive D:. Because junction points redirect
to elsewhere, you need to check your backup software does NOT follow
junction points; else, you'll end up with 2 copies of the same files
where one followed the redirection to the target path and another backed
up the target path.

Although Libraries are not supposed to use networked drives (because
they want to index the files in the path), you could use junction points
with libraries. I've never bothered to use the Libraries feature of
Windows 7. If you've defined a junction point, you could just use that
instead of attaching a Library to it. Depends on how you want to access
the remoted path and if you want its contents to get indexed for faster
searches. The following article mentions how to use Libraries with
junction points:

http://www.sevenforums.com/tutorials...rk-folder.html

Another possible solution (I don't have your setup to test) is to
configure Windows Explorer to launch separate instances of itself. In
WE, go to Tools - Folder Options - View tab and enable the "Launch
folder windows in a separate process" option. I don't know if that
works when you've relocated the profile folders using a mapped drive
because WE is going to show the special folders list at the top of its
tree pane. Those special folders are not shown if you to to Tools -
Folder Options and deselect the "Show all folders" option. Maybe not
having WE show those special folders would keep it from trying to
refresh on them to generate errors when they're not reachable.

Per VanguardLH:
So, in the past 3 days, has that been when your NAS box has been
clobbered or otherwise unavailable? This error occurs when the shell
(aka profile) folders are incorrectly defined in the registry or they
are missing. Since the remote host is inaccessible, the profile folders
are missing.

I did not relocate the problem directory (ies?). In the first
instance, there was some sort of LAN problem where the NAS box was just
unavailable. The cure was to reboot the router and NAS box.

In the second instance, one of my mirroring processes (mirroring the NAS
box to an old WHS box) ran amuck and deleted the "MyDocuments" folder on
the NAS share. The cure there was to restore from backup.

I'm going to stop messing around and just leave all the "My..." folders
on the system drive, ignore them, and do all my saves directly to the
NAS share.

I call this a bug. I might be incorrect in a strictly semantic sense,
but Windows really should issue some sort of informative message rather
than just stop being able to open any directory anywhere with no
explanation. If it were just the affected directory (ies) that caused
Win to throw the error, it might not be so bad - and one might have a
chance of figuring out there was something wrong with the affected
dirs.... but *all* directories and *all* files? Bug.
--
Pete Cresswell

Per (PeteCresswell):
I did not relocate the problem directory (ies?).

.... immediately prior to the problem.

Re-reading your post, I think you were referring to my initial act of
relocating the problem directories from the System drive to the NAS
box.... Guilty as charged... but I will remedy that.... -)
--
Pete Cresswell

PeteCresswell wrote:

Per VanguardLH:

This error occurs when the shell (aka profile) folders are
incorrectly defined in the registry or they are missing. Since the
remote host is inaccessible, the profile folders are missing.

I did not relocate the problem directory (ies?).

So what did you really mean when you said:

"I have "MyDocuments" relocated to a share on a NAS box."

I'm going to stop messing around and just leave all the "My..." folders
on the system drive, ...

Which again reinforces that you moved the shell folder(s).

Per VanguardLH:
So what did you really mean when you said:

"I have "MyDocuments" relocated to a share on a NAS box."

You saw the followup post, right?

If not:
I did not relocate the problem directory (ies?).

.... immediately prior to the problem.

Re-reading your post, I think you were referring to my initial act of
relocating the problem directories from the System drive to the NAS
box.... Guilty as charged... but I will remedy that.... -)
--
Pete Cresswell

(PeteCresswell) wrote:

You saw the followup post, right?

Yep but after I already dashed off my reply. Sorry.

Re-reading your post, I think you were referring to my initial act of
relocating the problem directories from the System drive to the NAS
box.... Guilty as charged... but I will remedy that.... -)

While relocating to a local drive seems okay (I haven't done enough
research to feel confident that local is okay), relocating to a
non-local (networked) path seems fraught with problems that aren't just
exhibited in Windows 7. When employees are disconnected from their
roaming profile when the PDC goes down, it is the highest priority to
get it back up and their employees working again. However, in many
cases, the profile folder of My Documents is not considered a high
priority rescue. Employees are required to save corporate documents
elsewhere. The main docs store for the company is still networked but
access doesn't necessarily require a domain login to get at them.

You could do the same and create your own "Pete's Docs" networked file
store but you'd still run into the problem of getting at them if the
remote host is down or inaccessible for whatever reason. I figure you
might want to look into synchronization to a network path using the
methods mentioned unless you come up with something better. You'd have
a local copy of the docs along with a remote copy. This wouldn't really
be a backup copy on the remote host because files you delete at the
local source will get deleted at the remoted copy. So you'd still want
to do backups to get at old versions of files.