none
Event ID 1509

    Question

  • Environment: running Server 2003 no more than 30 days off the latest updates and SPs, in application mode; running as a virtual machine in a vSphere install.  Roaming profiles, redirected folders.

    Maybe once every week or two I get an error 1509 on one of my two Terminal Servers.  Never the same user, but the problem is the same - access denied.  When I go in and look at the referenced file, on the file server it is fine; on the local server it is wrong - does not have a security tab while all the other files around it do.  Cannot delete it, take ownership of it, have to reboot the server after hours and the file just dissappears, to be recreated from the profile share on the next logon.  The user gets logged in with a temp profile, then the folders redirect with no problem.

    I found a setting I would like to try: computer configuration > policies > administrative templates > system > user profiles > do not check ownership of roaming profiles.

    I'm hoping this will allow the logon process to copy over the local bad file from the network profile share should it run into this in the future. 

    My question is: what are the gotchas?  Has anyone ever used this successfully to solve a similar problem?  Am I setting myself up for much larger problems than the occasional (and extremely annoying) temp profile?

    Thanks!

    -Paul

     

     

    Wednesday, July 28, 2010 2:05 PM

Answers

All replies

  • Whoops; wrong forum.
    Wednesday, July 28, 2010 4:46 PM
  • Old TS forum doesn't appear to be working.  So if you have an opinion about this setting, would love to hear it.
    Wednesday, July 28, 2010 7:06 PM
  • Hello,

    I thnk your problem already starts at logoff. The file is locked and therefore the profile is not unloaded and removed. Are you using any tooling like DELPROF or such to remove the profile.

    There is also a known problem for VMWare and profiles. please have a look at:

    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1317

    Regards Robert

    Wednesday, July 28, 2010 8:50 PM
  • Robert,

    Very interesting... I'll have to look at this one real careful.

    Wednesday, July 28, 2010 9:58 PM
  • Hello,

     

    According to your description, I understand that you get an Event ID 1509 error about copying profile.

     

    To resolve this issue, you may try the following methods:

    - Everyone was missing "Full control" sharing permissions. Granted "Everyone" Full control on the Share where roaming profiles are stored.

    - Copied the user profiles and deleted them from documents and settings except for the profile it was using.

    - Checked registry. In Profilelist, under the guid of a problematic user, confirmed that user profile is being used.

     

    Other Resolutions:

    ============

    Resolution 1:
    In most cases, run UPH Clean resolves most of the issues.

    Resolution 2:
    In one case, improper network configurations may cause this problem. For example, the network speed on the switch is set to Auto, while that on the NIC card is to 100 MB Full duplex. Set them both to the same setting.

     

    For your reference, I have included some known issues blow:

     

    After you install security update 885250 (MS05-011), you may not be able to view the contents of a subfolder on a network share by using Windows XP or Windows Server 2003

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;896427

    973835  Roaming user profiles and FSRM File Screening

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;973835

     

    Wilson Jia

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Thursday, July 29, 2010 2:40 AM
  • Robert,

    I found and removed the entry in the registry on both the involved Terminal Servers.  However I don't think this is the root of my problem: it only affects the first person logged in as the shared folders feature is "not designed for concurrent session access".  That first person is always the administrator.

    My suspicion is that you are right, something is happening at logoff.

    I haven't been deleting profiles.  Seems a little extreme - I can trace the problem to the one (random) file referenced in 1509.  As long as that file is deleted the logon goes well.  I can't delete the file and it doesn't show me security settings.  Nor can I reset security.  The only thing that seems to work is rebooting the server.

    I do have a temp workaround for when this happens: the user can log into the other terminal server.

    Thursday, July 29, 2010 3:24 PM
  • Wilson:

    Thanks for responding I appreciate the help.  I went through your reply piece by piece and struck out:


    - Everyone was missing "Full control" sharing permissions. Granted "Everyone" Full control on the Share where roaming profiles are stored.

    - Copied the user profiles and deleted them from documents and settings except for the profile it was using.

    - Checked registry. In Profilelist, under the guid of a problematic user, confirmed that user profile is being used.

    In these first two items, I would expect to always have the user get the error.  However it is never the same user, and the user can usually log in ok.  It is just every once in a while that this happens, never on the same user, and only on one of two terminal servers.

    I will certainly take a look at the registry to see if the profile is in use, locked open somehow, while a user is being prevented from logging in.

     

    Other Resolutions:

    ============

    Resolution 1:
    In most cases, run UPH Clean resolves most of the issues.

    UPH installed before going into production.



    Resolution 2:
    In one case, improper network configurations may cause this problem. For example, the network speed on the switch is set to Auto, while that on the NIC card is to 100 MB Full duplex. Set them both to the same setting.

     

    Link speed is set to auto-negotiate; only joker is if VMware ESX is messing with link speed somehow, but a glance through that did not find anything.

     

    For your reference, I have included some known issues blow:

     

    After you install security update 885250 (MS05-011), you may not be able to view the contents of a subfolder on a network share by using Windows XP or Windows Server 2003

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;896427

     

    Network share is on Server 2008, so doesn't apply.

    973835  Roaming user profiles and FSRM File Screenin

    Not getting an event id 1504.

    http://support.microsoft.com/default.aspx?scid=kb;EN-US;973835

     

     

    Wilson

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

     


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Thursday, July 29, 2010 3:50 PM
  • One thing about this, it is an intermittant problem.  Normally, the user can log in ok.  When this happens Event ID 1509 references a single file on the Terminal server.  When I look at the file, it is abnormal.  All the other files in the folder have a security tab in the properties sheet.  The referenced one does not.  As admin, I am not able to delete it, although I can delete other files in the folder. 

    The same file on the network share does not have the problem, and the file on the other terminal server doesn't either.  Which is why the user can log into the other server ok.

    I don't know what is causing this, but my thinking is that if I use the setting that allows windows to transfer the profile from the network share without first checking security this will go away.

    However, I don't really know what the implications of that are, and I'm curious if someone else has seen this.

    Thursday, July 29, 2010 3:57 PM
  • Hello,

    You can try to use procmon to see what is locking the file and making it impossible for the profile to unload.... Is this file related to any program installed particulair??

    Robert

    Thursday, July 29, 2010 7:25 PM
  • Here is an example from the event id verbage:

    "Windows cannot copy file \\<share>\TSProfiles\<domain.username>\Favorites\google maps - Bing.url to location C:\Documents and Settings\username\Favorites\google maps - Bing.url"

    It was the file on the C:\ drive that was all bent out of shape.

    I'll try procmon next time this happens - it could take a couple of days or it could be a couple of weeks. 

    What I am hoping is that by disabling security checks that file - C:\Documents and Settings\username\Favorites\google maps - Bing.url - will simply be overwritten from the profile kept on the network share.  What I am worried about is that I don't really understand what the implications of setting the profile copy to work that way are.  Also, I don't understand why the file would lose its security settings.

     

    Thursday, July 29, 2010 9:21 PM
  • Hi Pmolina,

     

    Thank you for your response.

    This 1509 event can happen if the destination path of the users profile is on a server with a long server and share name, e.g. \\servername\thisistheprofileshare
    As the file is stored locally on "c:\users\username" the filename for copying to the destination will increase when this prefix is changed to "\\servername\thisistheprofileshare\" leading to a path name is longer than the supported 260 chars.

     

    Wilson Jia

     

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    • Marked as answer by Wilson Jia Monday, August 02, 2010 8:38 AM
    • Unmarked as answer by Paul Molina Monday, August 02, 2010 7:20 PM
    Friday, July 30, 2010 6:54 AM
  • Wilson,

    That's good to know.  I can see how this could creep up in some circumstances.  Including path the last one had a file path and name of 108 characters, the file was named:

    comcast.net News, Sports, Video, TV listings, Email and more!.url

     

    -Paul

    Friday, July 30, 2010 1:11 PM
  • Robert,

    Had another one stick again this morning.  Again, it was a *.url that did not have security settings.  I couldn't delete it.  While I was trying to delete it, there was an entry "deletion pending" in procmon.  But once that errored out nothing.  I think the file is just mangled.  I will remove it tonight probably by rebooting the server, although will try some other things.

    I'm also going to put in place a script to reboot the two terminal servers nightly and will restrict idle sessions to 3 hours.

    I looked at the GP that prevents security checking which I alluded to earlier, but on closer reading that only applies to the network version of the profile, not the cached local version.  Its the local version that is giving me trouble.

    And if that doesn't work I guess I will have to open a ticket with MSFT.

    -Paul

    Monday, August 02, 2010 7:27 PM
  • Hi Paul,

    Can you logon as administrator account to take the ownership of the problematic file? Then delete it.

    It seems only the long character files got this issue. I would suggest you reduce the \\sever\share\ path name character to see if the issue goes away.

    Best regards,

    Wilson Jia


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Tuesday, August 03, 2010 2:14 AM
  • Wilson,

    I'll keep an eye on the file length issue.  The part I control (\\server\share is only 17 characters including slashes, so thats pretty tight already:  \\xxxx\TSProfiles

    I tried deleting it, using the command line to delete it, and modifying the permissions using CACLS to give the administrator back the permission to delete it.  I was using the domain admin, not the local admin, you think that makes a difference?  CACLS was not allowed to touch the file.

     

    -Paul

     

     

    Tuesday, August 03, 2010 4:46 PM
  • Hi Paul,

    Thank you for your response.

    Are you able to touch the problematic file's security -> advanced -> Owner page?

    If so, please click "Edit..." button and choose the domain admin account which you are using.

    Does it work?

    Regards,

    Wilson Jia


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Wednesday, August 04, 2010 3:37 AM
  • Wilson,

    Sorry, I was out of the office for a couple of days there.  The file that is referenced in the error message will not have a security tab at all.  It will be the only file in the folder without one.

    While on vacation I  did look around a little, and found some references to my problem and tried to apply them:

    http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/2003_Server/Q_24781775.html

    This references KB883260 - http://support.microsoft.com/kb/883260 as a solution to the problem, however this kb refers only to XP sp2.  Still, I made an attempt to enable this by enabling the default risk level for file attachments and setting the default level to low.  Then I enabled the "Inclusion list for high risk file types" setting and specified .ade file types as the only (it requires one type) type on the list.  And no, I am not happy-happy about loosening security like this as I'm not real clear about the potential consequences.

    I did this the evening of the 4th and haven't seen a 1509-1515-1511 event id with "access denied" on 1509 the cause since I did this.  Doesn't prove anything, though, as this is such an intermittant problem.  I did see one 1509-1504 event id combo with the cause in 1509 listed as "insufficient resources exist" - one of these on each server.

    Monday, August 09, 2010 8:20 PM
  • I also tried to redirect the favorites folder instead of have it as part of the roaming profile - but it wouldn't.  GP setting was greyed out - I think because this is a Windows 2008 domain but not sure of that.
    Monday, August 09, 2010 8:27 PM
  • Also found a minor problem: the underlying VMware ESX servers were ~ 5 minutes behind the domain time.  Fixed that; but the T-servers in question were in sync with domain time.  It became a problem because I instituted as a what-the-heck-why-not solution nightly reboots.  Noticed that the machines were rebooting at the proper hour but then the time would set back 5 minutes and they would reboot a second time when the hour of the reboot came around again.  I didn't notice it at first because I would stop scrolling the log when I hit the second reboot.

    Tuesday, August 10, 2010 5:03 PM
  • I'm getting this too on Sever 2008 used at Citrix server (across all 4 servers). Mandatory profiles go corrupt, can be deleted via system/ advanced settings / profiles . Re-created automatically on next login but go corrupt again soon after. Does seem to be the Temp Internet  files folder. same as above you lose the security tab and have to take ownership, reset permissions etc. Have deleted test users profile and going to test with a few long URLs to see if it goes corrupt straight away.Should show if it's just the length of URL that causes it?

    Profiles are stored on EMC storage presented out as windows network share. No problem with roaming part of profile , mydocs, appdata are handed off to the network.

    • Edited by TPNVT Wednesday, August 11, 2010 12:46 PM missed detail
    Wednesday, August 11, 2010 12:43 PM
  • TPNVT:

    How often are you getting bad profiles?  Is it constant or just every once and a while?  I had a rash of them the last week or so - 1 or 2 a day - but now its back to being quiet.  Doesn't mean it is fixed, it might just be dormant.  The frustrating thing is that I can't point to a cause or event to reproduce this, so I can't test a specific fix.  I'm reduced to just trying things. 

    I think if this starts happening again I will open a ticket with MSFT.

    Wednesday, August 11, 2010 2:20 PM
  • Mine seems to be when I re-create the profile it stays good for a while then once turns bad I get constant error message at logon. Because my appdata/mydocs/ favourites are redirected I can blow away the profile and it just recreates a new one from the mandatroy settings. since my last post I just did this and messed around on youtube for a bit, logged off and it's corrupt already. (I logged on and off a few times without using IE first without any error in event log ) Looks like the file length to the end of the IE cache ??

    then the 'randomness' is down to what the user has been doing on the internet??

    do you have a test user you can use to sit and browse internet to try to create long file paths under IE history / cache?

    Here's my event from event_log

    Log Name:      Application
    Source:        Microsoft-Windows-User Profiles General
    Date:          11/08/2010 15:46:36
    Event ID:      1509
    Task Category: None
    Level:         Warning
    Keywords:      Classic
    User:          domain\a.user
    Computer:      computername.domain
    Description:
    Windows cannot copy file C:\Users\a.user\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\2E2JSEA\0,480x360;mpvid=AASNj5sG7bJ6RlR;!c=37;k2=2;k2=14;k2=1131;k2=1135;kvid=VJvcyDbyzyA;shortform=1;k4=14;kpid=337;kga=-1;kgg=-1;kcr=gb;khd=0;ytexp=907113.904515[1].asx to location The filename or extension is too long. . This error may be caused by network problems or insufficient security rights.

     

    Wednesday, August 11, 2010 3:20 PM
  • Mine are going the other way:

    \\fileserver\TSProfiles\username.domain\Favorites\Hotel Donaldson.url to location C:\Documents and Settings\username\Favorites\Hotel Donaldson.url. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator.

     DETAIL - Access is denied.

    The bad file is the one in the C:\ drive that won't allow the network version to overwrite it.  Nothing in the temp inet files has caused problems.  Also, the cure has been to reboot the terminal server rather than recreate the profile.  The problem doesn't seem to stick once a reboot has been performed.

    Are your 1509 messages followed by event id's 1515 and 1511 or by 1504?

     

    Wednesday, August 11, 2010 7:10 PM
  • No, just a bunch of 1509 errors followed by

    1534- too many copy errors then

    1540 roaming profile not synced error.

     

    Did you say you had permissions errors on the local c:\users\profile folder? that will cause the copy back from network to fail so I think the root cause of our problem is the same. Permissions getting screwed on local profile? for you it's the IE favourites, for me it's the IE cache folder, but think same issue...?

     

     

     

     

    Thursday, August 12, 2010 9:38 AM
  • Same symptom, but the follow on events are different.  Have you looked at your AV/Malware protection at all as a possible source?
    Thursday, August 12, 2010 1:11 PM
  • No. I've been testing again today and IE cache corrupted profile after 10 minutes of youtube video. recreated profile and have been logging on and off all day without using IE with no further problems. I'm pretty sure as soon as I use IE again it will corrupt the cache.

     

     

    Thursday, August 12, 2010 1:15 PM
  • Stable for 9 days so far...  I think it may have indeed been  KB883260.  Or the nightly reboots.  Or re-sync'ing the system clocks.
    Monday, August 16, 2010 9:13 PM