Server 2003 SP2 acting as DC, FS, PS.Clients are all XP Pro SP3Roaming profiles in useFolder redirection in useProblem occurs with *some* user profiles, but not all - doesn't matter which client is used to log inAfter getting reports that some users were getting error messages that their roaming profile could to be loaded, I was able to see the 'access denied' error message pointing to \\server\profiles\%user%\Favorites\Links\msn.com and the details that the system was unable to copy the file to the local drive.Looked like a clear security settings problem (though odd to occur out-of-the-blue). I checked permissions on the links folder and all are set per "the book" and have been working fine previously. I attempted to change permissions on the offending Links files but access was denied even though I was physically at the server and logged in as the administrator. Ownership was set to the Administrators group so I attempted to take ownership as the administrator but access was denied (what the?). I attempted to delete the file but again, access was denied.FYI, when checking properties on the individual files, I only see the General tab, not the Web Document or Security tabs (probably b/c I don't have access :-). So my attempts to take ownership and otherwise change NTFS settings were at the Links folder level and attempting to push settings down to all child folders and files - access denied.I'm starting to think virus, but I can't find any mention of this behavior anywhere on the web.This is becoming crippling as it is preventing users from accessing needed files.Any thoughts?

Quick UPDATE: After more research and thinking, I also just tried using the cacls command while logged on locally to the server as the Admin - no luck, I get a return of Access Denied for the known problem files. All other files in the same Links folder execute just fine.

Hello, Thank you for your post here. From the description, some domain users cannot access some specific files in the roaming profile. By Default, the profile owner should have the ownership of all files in the profile including those links. I believe that you used to copy/migrate those roaming profile without keeping the ownership and permissions properly. As a quick workaround, I'd like to suggest you to recreate those problematic user profiles and copy the files and folders in the old profile to the new created one on the client side. If you don't want to recreate those user profiles, you may check how it works if you change the permissions/ownership from the client side with the profile owner logged on. If you have any questions or concerns, please do not hesitate to let me know.

Thanks for the help Miles.To clarify, some domain users have files in their roaming profile (so far, all the 'offending' files are in the users /favorites/links folder) which cannot be accessed by anyone, including the local and domain admin even while logged in locally (security tab doesn't even show). Other files in the same folder are fully accessible.With several days trying to resolve this under my belt, I think there is a process somewhere accessing the files. This in turn is preventing access by anyone (including the server Admin). So I don't think it is an NTFS security permissions issue (though that may be an other issue that needs to be addressed based on your posted suggestion).By default, the profile owner does have ownership of all files in the profile. However, for several of the profiles (including some that are having problems and some that are not, yet, having problems) I have taken ownership as the server admin so I could access the folders for a variety of admin purposes. I did NOT change ownership back to the profile owner (though it sounds like you are saying I should do this as a matter of best practices). So when the profile is pushed down to the client during user logon, the file ownership remains with the server admin and not the profile owner (though the profile owner does have NTFS permissions set as full control). Am I understanding this correctly?I did recreate one of the problematic profiles (my own which is a member of the domain admins group) but I cannot delete the problem files and therefore cannot delete the old profile b/c access is denied to the problem file (for now, I just renamed it and left it there).Overnight while the server was able to be down, I did reboot and was able to eventually access the problem files (though not on the first reboot), but I think the user was still logged in to one of the clients. I figured there must be a process that is maintaining access to the offending files but I cannot determine which process and rebooting the server constantly isn't a workable solution. This morning, my new profile pushed down just fine (other than losing the 'my folders' that are redirected to the server) but after logging off the second logon failed b/c yet a new .url file in the /links folder had 'access denied' and again the security tab is missing on the server copy. So some process seems to be holding that file, but I'm stumped as to how to find it. FYI, the new .url link that is causing the problem is a linke to ebay.com and one of the previous .url files was a link to gmail.com so these don't seem to be especially unusual files.On a possibly related note, one of the users having problems mentioned that her links toolbar was showing odd file names that were not actually even links. All she could recall is that they started with the letter 'p' followed by a series of seemingly random numbers and allending with the extension '.url' this is particularly odd given that we use group policy to keep all user link toolbars the same.I'm open to any suggestions at this point (particularly something to help me determine the process that is holding the files).Many thanks!

Hi, Thanks for the update. To identify which users open the link files in the roaming profile, you may check the Open Files status in Computer Management. 1. When the issue happens, on the file server that holds the roaming profiles open the Computer Management. 2. Check the file access status in System Tools--->Shared Folders--->Open files. If the client read/lock the link file in the roaming profile, it will help us to narrow the issue to a potential culprit application on the client. To isolate the issue from any 3rd party app on the clients, you may check how it works if you perform a clean boot : a) Click Start->Run...->type msconfig and press Enter.b) Click Services tab and select Hide All Microsoft Services and Disable All third party Services.c) Click Startup tab and Disable All startup items.d) Click OK and choose Restart.e) After reboot, check whether the problem still occurs.f) If there are no more problems, please use the above steps to enable services and startup items one by one in order to figure out the root cause of this issue. If you have any questions or concerns, please do not hesitate to let me know.

I have a customer who is experiencing the exact same issue. it only affects .URL-files, and it started to occur after I upgraded Internet Explorer on their terminal servers to IE 8. I have narrowed it down to be related to ADS (Alternative Data Streams), as it only occurs on URL-files with alternative icons, which are stored in ADS's (favicon). If you use ADSspy (or any other tool that can remove ADS's) to remove the ADS on the files, the problems are resolved, but they reappear when they visit any of the sites they have .URL-files to that use ADS. Another temporary workaround is to run chkdsk on the volume that holds the roaming profiles, with the autofix option, without scheduling chkdsk to run on next reboot. This deletes the affected .URL-files. The terminal servers are Windows 2003 SP2, and as mentioned, with IE8. It seems to me that it is a bug in IE8, since the problem appeared immedialtely after upgrading to IE8 PS: There is a growing number of customers reporting this problem, so I really hope MS can put some resources into solving this soon Morten Starvik Consultant Contra

90% of the .url that I am having an issue with is the preloaded microsoft urls deleting them has helped but it seems to be a growing issues my users are freaking out about.

Some more information to add to the puzzle.Using MS Process Monitor v2.8 (a free tool from MS which I highly recommend if you are not already using it!) I discovered that the reason I could not see a security tab, delete the .url files, or take ownership was b/c I could not access the files. Not b/c of missing or incorrect rights, but b/c the files were already being accessed (and locked) by another process.The other process was cidaemon which appears to be part of the MS Server indexing service (though I've come across a few threads that suggest a virus - but no verification yet).For testing purpose and a quick work-around, I stopped the MS Indexing service on the DC and the files were immediately released and everything is back to normal (roaming profiles loading just fine, redirected folders working just fine, security tab is back, I can take ownership - though no need anymore). In short, this was/is clearly the problem.I think I can safely leave the MS Indexing service turned off without ill side-effects, but I'd like to determine why this all started in the first place - if for no reason other than to rule-out a virus that has been missed by our software and hardware protections.I hope this helps others - I'd again definitely download and run the free MS Process Monitor program on the server and then use the search feature by entering the name of the .url file giving you problems and see what processes are accessing the file. Please post if it turns out to be the cidaemon process (maybe a new bug floating around?).

Hi, Thanks for the update. From the description, the Microsoft Indexing Service is the culprit. We do appreciate your sharing on the resolution and the steps how you figure it out. I am sure that other community members will benefit from your findings. Thanks.

The Indexing service can definitely be the culprit, as we set up a new fileserver to host the profiles at the same time as we upgraded to IE8 and the problems started, anf it of course had the indexing service running as default. I just stopped the Indexing service, and from what I can see for now, the files that previously cause problems are now accessible...I will wait and see for a couple of days before I draw any conclusions, but it might seem like you're on to something here...brilliant!

I recently updated our WIN XP clients to IE8 and some people with roaming profiles experienced this exact same problem. I went to our WIN 2003 SP2 server that stores the roaming profiles and, sure enough, the cidaemon was running. I stopped and restarted the indexing service as recommended here. The immediate problem is now fixed. However, I am still not sure what the root cause of the problem is.Will Microsoft fix this?

OK, we had exactly the same problem. Stopping Indexing Service does resolve all issues immediately. A bug?

I am having the exact same problem BUT with a Windows 2008 server. I am NOT running the Windows 2003 Indexing Service nor am I running Windows Search Service. How exactly do I fix this? I am getting more and more users unable to log on due to access denied on urls.

Update:The only files that are denied are the urls that have custom icons. And they are denied due to "The system cannot find the file specified." Again, this is only the urls with custom icons. All of the other urls are fine.

hello guys, the exact same problem on my part, except it happens on .URL files in windows update's SoftwareDistribution folder resulting in some updates failing download and not being installed. This way I have found that issue here. This is Windows 2003 SP2, the cidaemon.exe is version 5.2.3790.3959. Process explorer shows it locks even other SoftwareDistribution files. some other points to consider if somebody from MS would like to dig deeper: a) symantec antivirus installed, I have tried to stop the services and unload the drivers but still no releasing happens (no restart tried yet) b) the server must have been configured with proxycfg to enable Windows Update to download the files - may be indexing service is trying to download the target URLs and is not able to use the proxy? c) isa firewall client is installed on the server, but currently disabled d) wow, I have just stopped the System catalogue in the properties of indexing service and the .URL file DISAPPEARED!

some other symptoms - once the System catalogue has been started again, the behaviour reappears regardles symantec antivirus is completelly out of operation. So this is definitelly issue somewhere between indexing service and ie 8. for those who might have the same problem with windows update to enable them googling here: FATAL: Failed to move file from C:\WINDOWS\SoftwareDistribution\Download\...\update\update.url to C:\WINDOWS\SoftwareDistribution\Download\...\update\update.url (hr = 80070005) after 10 retries ondrej

uuu, the final resolution: the cause was that the server needed proxy for accessing HTTP. its default gateway doesn't allow the HTTP traffic at all, so all services must use the web proxy. Once I enabled the HTTP traffic through the default gateway, it seems like the Indexing Services (may be the icon COM module from IE trying to update the icon) tries to follow the .URL and once it is possible without proxy, it works fine! So this seems to me as a bug in IE8 probably. The resolution is either: a) disable Indexing Services b) or disable just the System catalogue c) enable HTTP access without proxy ondrej.

I have same problem. Can you please to precise: - is it ok to turn off Indexing service on a server, or I should do it at local machines? - what does it mean exactly to "enable HTTP access without proxy", where can I do it?

Indexing Service was our issue as well. Two of our 15 servers that we converted to IE8 had the profile issue. And, when I finally came across your suggestion to disable Indexing, I checked and it was enabled and set to Automatic on only those 2 servers. All the working machines had it disabled already. Thanks so much. It stumped my co-worker all last week.