Skip to content

November 19, 2015

12

Visual Studio 2015 Breaks New Logins

Update: I can confirm that this issue is fixed in Visual Studio with Update 1.

I recently ran into an issue where after pushing out new Visual Studio 2015 installs (with SCCM), new users could not log into those machines. When trying to log in with a new user, the following error occurs: “The User Profile Service failed the logon. User profile cannot be loaded.”

When looking at the Event Logs, I saw access denied errors related to failing to copy some files to the users new profile from C:\Users\Default. (This hidden default profile is what all new user profiles are based from.) 

In doing some research, I saw that there were some similar issues with Visual Studio 2013, but those issues were fixed in later updates.  The root cause for Visual Studio 2015 appears to be similar to what the issue was in Visual Studio 2013; however, the affected files reported in the event logs are different.

In my case, the files in these two directories only had permissions for SYSTEM and Administrators.
C:\Users\Default\AppData\Roaming\Microsoft\VisualStudio\14.0\FeedCache
C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache

This situation results in Access Denied because the new user account can’t copy these files. (Even if the new user is an Administrator, it still fails if UAC is turned on).  However, the parent directory (FeedCache) has the necessary permissions for this to work. To fix this issue, we simply had to turn inheritance off and then back on for these specific files (this causes the ACLs to get updated from their parent). Once these permissions were updated, then new users were able to login successfully.

I did most of my testing using SCCM to handle the install silently, either via a Task Sequence or Software Deployment. I am not for sure if this issue always occurs when Visual Studio is installed interactively.

To streamline this fix, I wrote a powershell script that can be run after Visual Studio is installed. For example, if installing via a SCCM Task Sequence, you can simply run the script as the next step.  Here is the script that I wrote:

function ResetInheritance ($Path)
{
    # Get Current ACL
    $ACL = Get-Acl $Path
    # Disable Inheritance
    $ACL.SetAccessRuleProtection($true, $true)
    Set-Acl $Path -AclObject $ACL
    # Enable Inheritance
    $ACL.SetAccessRuleProtection($false, $false)
    Set-Acl $Path -AclObject $ACL
}
# Get Files to fix
[array] $Files = Get-ChildItem "C:\Users\Default\AppData\Roaming\Microsoft\VisualStudio\14.0\FeedCache"
[array] $Files += Get-ChildItem "C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache"

# Fix each file
foreach ($File in $Files)
{
     ResetInheritance -Path "$($File.FullName)"
}
12 Comments Post a comment
  1. Colin Atkinson
    Nov 26 2015

    This is the exact same issue I am having. When I run your script, I receive the below error:

    Set-Acl : The security identifier is not allowed to be the owner of this object.
    At line:7 char:12
    + Set-Acl <<<< $Path -AclObject $ACL
    + CategoryInfo : InvalidOperation: (C:\Users\Defaul…ED5A5F-File.xml:String) [Set-Acl], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetAclCommand

    Set-Acl : The security identifier is not allowed to be the owner of this object.
    At line:10 char:12
    + Set-Acl <<<< $Path -AclObject $ACL
    + CategoryInfo : InvalidOperation: (C:\Users\Defaul…ED5A5F-File.xml:String) [Set-Acl], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetAclCommand

    Set-Acl : The security identifier is not allowed to be the owner of this object.
    At line:7 char:12
    + Set-Acl <<<< $Path -AclObject $ACL
    + CategoryInfo : InvalidOperation: (C:\Users\Defaul…ED5A5F-File.xml:String) [Set-Acl], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetAclCommand

    Set-Acl : The security identifier is not allowed to be the owner of this object.
    At line:10 char:12
    + Set-Acl <<<< $Path -AclObject $ACL
    + CategoryInfo : InvalidOperation: (C:\Users\Defaul…ED5A5F-File.xml:String) [Set-Acl], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetAclCommand

    Do you have any idea why this is?

    I have had a very similar issue in the past which I have fixed with a CACLS command but I would rather use Powershell if possible.

    Reply
    • Colin Atkinson
      Nov 26 2015

      Sorry I should have googled this first. I fixed it by replacing
      $ACL = Get-Acl $Path
      with
      $ACL = (Get-Item $path).GetAccessControl(‘Access’)

      Reply
      • Brent
        Nov 28 2015

        I’m glad this helped and that you were able to tweak the script to make it work in your environment. Not sure why my environment didn’t require adding the GetAccessControl method, but I am using Windows 10 for this thou. Hopefully Microsoft will fix this issue in the near future…

        Reply
  2. Marc
    Dec 29 2015

    Same issue when deploying from SCCM …

    Reply
  3. Marc
    Dec 29 2015

    FYI – Simply deleting the Blend and Visual Studio from the Default\AppData\Roaming location will fix it as well.

    … Might as well let Blend & VS create those directories on the fly when the software is launched versus new user login. It will be more safe in my experience to only keep what is needed in the Default User folder.

    Reply
  4. Graeme
    Feb 7 2016

    Had the same issue with installing Visual Studio via SCCM. I use the following to reset the permissions for the effected files. Note that I added a test to ensure that the folder actually exists before resetting the permissions. Without the test-path the script would fail if the folder named didn’t exist.

    If (Test-Path ‘C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache’)
    {
    $FolderACL = Get-ACL -Path ‘C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache’
    Get-ChildItem ‘C:\Users\Default\AppData\Roaming\Microsoft\Blend\14.0\FeedCache’ -Recurse | Set-ACL -ACLObject $FolderACL
    }

    Its not elegant but it gets the job done.

    Reply
  5. Will
    Mar 3 2016

    I’m having this same issue with Visual Studio 2015 Enterprise edition deployed via SCCM. The deployed product says it has update 1, the xml files in the FeedCache folders only seem to appear after the first user has logged on, run Visual Studio and logged off again. The files don’t get their inherited permissions, only SYSTEM and Administrators have access.

    I deployed to a system yesterday probably for the first time we had left a long gap between building the OS and installing the package and not seen the issue on this system. Most of the other deployments have had the issue and in some cases the issue was masked because the users were local admin rights so it didn’t prevent them logging on, but then stopped SQL from running.

    Is there any acknowledgement of the issue from Microsoft, if it’s fixed in update 1, you’d think it would be mentioned somewhere?

    Reply
    • Brent
      Mar 9 2016

      No, surprisingly I couldn’t find anything from Microsoft to acknowledge this was fixed in Update 1; but I haven’t been able to reproduce the problem since Update 1.

      Reply
  6. Emmanuel
    Jun 6 2016

    Using chef to setup Visual Studio 2015 Update 1 (setup ran silently with the local system account), I still have the issue.
    But your script works perfectly. Thanks!

    Reply
  7. Graeme
    Jun 6 2016

    I just installed Visual Studio Enterprise 2015 Update 2 via SCCM and I am still seeing the same issue with the Feedcache folder.

    Reply
    • Brent
      Jun 7 2016

      I just tested this with Update 2 in my environment and wasn’t able to reproduce the problem, not sure that might be different. If issue remains thou, I would suggest keeping the workaround in place.

      Reply
      • Graeme
        Jun 8 2016

        I was certainly hoping that the issue had been resolved. I downloaded the web installer for Visual Studio Enterprise 2015 Update 2 and ran the /LAYOUT command to download all the files. I ran the /CreateAdminFile command to create an updated AdminDeployment.xml file. I modified the XML file to install all of the core Visual Studio components and ignore the web updates.

        I then created an application to deploy Visual Studio from a network share using the /adminfile /quiet /norestart /productkey switches. The application was set to “Install for System”, “Whether or not a user is logged on”. I ran the application from Software Center and once successful restarted the computer and attempted to logon using a new user account.This failed with the Event logs pointing to the FeedCache.xml files as the culprit.

        Reply

Share your thoughts, post a comment.

(required)
(required)

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments