Fixing Offline Files in Windows Vista

Published Monday November 03, 2008

Details

User Accounts window

I like the Offline Files feature of Windows Vista, but lately it always thought that I was offline even when I was on the network and could successfully ping the server. I did not get an answer from other folks after posting on several forums (here is one) so I set out to troubleshoot it myself. Since this is related to networking, I started my investigation using Wireshark, which is an awesome, cross-platform tool for looking into the network traffic on a given NIC. After stopping all of my networking activity I went to a folder with Offline Files set and noticed that my logon was failing. Unfortunately, I did not take a screenshot of the output, but it was something along the lines of STATUS_LOGON_FAILURE. That error pretty much explains what’s happening, somehow Windows lost my credentials for the specific server and wasn’t kind enough to ask me again :)

Stored Credential Properties window

To fix this, here is what you have to do.

  1. Start > Control Panel > User Accounts. This should take you to the User Accounts control panel and default to showing the properties of your current user.
  2. On the left side you should have a task called “Manage your network passwords,” click on that.
  3. Click Add.
  4. In the “Stored Credentials Properties” enter the name of the server (e.g. myserver1) or domain (e.g. mycomanyname.com) in the “Log on to” field.
  5. Fill out the User name and Password fields, leave “A Windows logon credential” checked, and click OK.

Doing this will save your authentication information for that server or domain. Wait a few minutes and pretty soon Offline Files should start seeing the server. If it still does not work then you might want to restart your computer so everything refreshes (I am sure there is a better way to “refresh”).

Hopefully this fixed your problem, leave a comment if it did not, and if you have any suggestions/better solutions, thanks!

Comments

12:10 p.m. Friday Jan. 9, 2009 (about 2 months, 1 week after publishing)
Thanks! trafsta
Nice! Thanks for the workaround. It will help with a few users but unfortunately for the majority of users who have their password changing every 30 days and who are not too computer savy this isn't the ideal solution.

Has anyone else found a better solution? Perhaps an unreleased Windows hotfix or something? I know this only started sometime between Sep-Nov of 2008, so I'm guessing a MS hotfix released during that time is to blame. Prior to that our users never had this issue when reconnecting to our network or when resuming from hibernation after previously being off of the network while working offsite...
8:54 p.m. Friday Jan. 9, 2009 (about 2 months, 1 week after publishing)
RE: Thanks! farhan
I didn't think about this from that point of view, but I think that would definitely be a problem. It might be worth checking with Service Pack 2 Beta installed. MS is actively looking for feedback on SP2 Beta so if they haven't fixed it already then you could report it there and it might actually get fixed. Actually, why don't I point them to this blog entry :)

By the way, you can find the SP2 feedback at https://connect.microsoft.com/site/sitehome.aspx?SiteID=749
3 p.m. Thursday Jun. 25, 2009 (about 7 months, 3 weeks after publishing)
Success! trafst
This issues continued to occur under Windows Vista SP2, and Windows 7 RC... so I decided it was time to spent a ton more time on it. As it turns out, another issue that I was having with the Windows Installer failing to install certain applications ended up being related to this problem as well (see http://www.experts-exchange.com/Microsoft/Server_Applications/Q_24404579.html if you have an EE account to check it out).

Our users My Documents folder is a UNC path of "\\<server>\home$\<username>\My Documents". The windows installer "Error 1324. the path My Documents contains an invalid character." error was resolved by correcting server-side permissions which I discovered after some digging. What I found was that the \\<server>\home$ share file-level security permissions did not allow "Domain Users" to list contents of the root. The users only had permissions to their own subfolder of that root.

So, for example, 'testuser', could access \\<server>\home$\testuser, but could not access \\<server>\home$ (access denied).

I tried giving the group "Domain Users" special permissions on to the root home$ folder applied to "This Folder Only" and removed checkboxes on "read permissions" (so they only have "traverse folder/execute file", "list folder/read data", "read attributes", and "read extended attributes" to that one folder only, not subfolders [which would be a huge security issue :)])

Doing this instantly solved the problem with the windows installer 1324 errors. Users receiving the windows installer error could now install software without an issue.

About an hour later I said, hey, maybe this was the problem with offline files staying offline and disconnected when returning from hibernate/sleep... so I borrowed a user who had this issue's laptop and tested it out thoroughly the past few hours... and whadda know! The problem is now gone. I can hibernate, undock, resume (now on wireless) and files in My Documents were still available in online mode. I then hibernated, docked, and resumed, and everything was once again fine!

I hope this resolves the problem for many others out there. I probably wasted many many days in total resolving this little problem. ;)
8:33 p.m. Wednesday Jul. 1, 2009 (about 8 months after publishing)
RE: Success! farhan
trafst, thanks a lot for explaining your specific scenario, I am sure people will appreciate it. Talking technical, I guess the programmer must be catching a very general exception instead of the specific one they should have caught :) This tends of be a very common bug in programs.
Add new comment