If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
"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 |
Ads |
#2
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
(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. |
#3
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
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 |
#4
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
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 |
#5
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
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). |
#6
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
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 |
#7
|
|||
|
|||
"Server Execution Failed": Bug or Feature?
(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. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|