Well, the title pretty much says it all.  I'm installing SQL Server 2014 Developer Edition on Windows 8.1 Pro.  The installation uses domain service accounts for all the services.  The installation progress well until the end.  Then, I get the following message:

Updating permission setting for folder C:\Windows\Temp failed.  The folder permission setting were supposed to be set to (and an ACL list followed by what looked like a object sid).

I'm running setup as administrator.

I tried to manually set the permissions, but that's not working (access is denied).  I also turned off user account control and hit retry.  That failed to.

So, before I go in there and take ownership of everything on the C drive, and grant myself full control over every file on the computer, I thought I ask for what I'm "supposed" to do.  I'm not going to tolerate this file control crap for very long.  I have better things to do.

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator 8 hours 5 minutes ago

Hi Alberto,

No good there.  The accesschk returns all three of the permissions mentioned (and many others) in that article for my account, the local admininstrator account and the domain administrator account (I'm the domain admin, too).

The administrators group is a member of all the policies mentioned, too.  That confirms the accesschk output, I suppose.

I'm going to abort this installation and reinstall while logged in as the local administrator.  If that fails, I'm going to run a SQL Server 2012 Developer Edition install.  I know that install works for my Windows 7 machines.

It's odd that the only feature that shows failed in "Reporting Services - Native".  Everything else looks great.

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator Wednesday, March 25, 2015 11:00 PM

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator Wednesday, March 25, 2015 11:00 PM

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator Wednesday, March 25, 2015 11:00 PM

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator Wednesday, March 25, 2015 11:00 PM

Hello,

Even when you are logged in as Administrator, domain policies may be restricting some important user rights. Please ask the Active Directory administrator on your organization about the user rights mentioned on the following article.

http://support.microsoft.com/en-us/kb/2000257

The command c:\> Whoami /priv may be helpful.

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

• Edited by Alberto MorilloMVP, Moderator Wednesday, March 25, 2015 11:00 PM

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

• Proposed as answer by Michelle LiMicrosoft contingent staff, Moderator 23 hours 52 minutes ago
• Unproposed as answer by Greg Wilkerson 19 hours 24 minutes ago

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

• Proposed as answer by Michelle LiMicrosoft contingent staff, Moderator Thursday, March 26, 2015 7:12 AM
• Unproposed as answer by Greg Wilkerson Thursday, March 26, 2015 11:40 AM

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

• Proposed as answer by Michelle LiMicrosoft contingent staff, Moderator Thursday, March 26, 2015 7:12 AM
• Unproposed as answer by Greg Wilkerson Thursday, March 26, 2015 11:40 AM

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

• Proposed as answer by Michelle LiModerator Thursday, March 26, 2015 7:12 AM
• Unproposed as answer by Greg Wilkerson Thursday, March 26, 2015 11:40 AM

An update.

Since the reporting services installation was the only thing failing, I check up on that using the reporting services configuration manager.  The reporting services were not started, so I started them (or tried to).  The start failed and the message "Access is denied" was logged in the event log.  So, I made the SSRS service account a local admin and the service started.  Cool!

I briefly looked around for proper security configuration for that account.  I know that stuff is out there.  But, I ALWAYS install with the service accounts so I don't have to go through the punishment of setting those account rights manually. 

But, making the account a local admin at least go the services to start. I'm going to re-install with that account in the local admin group before I start and see where that takes me.

So, I as see this, there is a bug in the install that is not properly setting the rights for the reporting services service account.  More on that later.

• Proposed as answer by Michelle LiModerator Thursday, March 26, 2015 7:12 AM
• Unproposed as answer by Greg Wilkerson Thursday, March 26, 2015 11:40 AM

Hi Greg,

Glad to hear that the issue is resolved and thanks for your post to share your solution. That way, other community members could benefit from your sharing.

Reagrds,
Michelle Li

Well, configuring the SSRS domain account as a local admin didn't fix it.  Still the same error:

Hmmm.....

Anyone?  Anyone at all?

TITLE: Microsoft SQL Server 2014 Setup
------------------------------

The following error has occurred:

Updating permission setting for folder 'C:\Windows\Temp' failed. The folder permission setting were supposed to be set to 'D:(A;OICI;0x1200af;;;S-1-5-80-1667640717-1742235589-1546145076-307360837-3521363061)'.

Click 'Retry' to retry the failed action, or click 'Cancel' to cancel this action and continue setup.

For help, click: http://go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=12.0.2000.8&EvtType=0x0ADF5303%25400xBB814387

------------------------------
BUTTONS:

&Retry
Cancel
------------------------------

Hello,

Could you try to put that folder Full Control permissions to everyone just temporarily, while you run SQL Server setup?

Hope this helps.

Regards,

Alberto Morillo
SQLCoffee.com

Alberto,

Windows won't allow me to modify the permissions of that folder at all.  Not under my account (a domain admin), the domain adminstrator, or the local administrator account.

I was looking at a SQL Server 2014 Standard edition installation I did a few weeks ago on Windows Server 2012.  The C:\Windows\Temp folder has no such restrictions on the folder and the user "ReportServer" has read/execute list rights to that folder.  I'm not sure where this "ReportServer" user is coming from.  It's not a domain user and doesn't list as a local user.

I don't know if this is a Windows 8.1 thing, or something to do with SQL Server 2014 Developer vs. Standard. Or, there's some other voodoo going on.

I'm going to do this install using the local admin account and see if that makes a difference.  Running it "as administrator" doesn't work.

Well, an installation while logged in as the local administrator, and taking all the defaults (pretty much just clicking next all the way through - except installing everything) failed with the same error.  So, that tells me it's probably not service account rights (glad about that).

Hmmmm.

I think I have it figured out.  It's the virus software (Avast).  That program normally doesn't get in the way of installation.  And, if I suspect it does, I just disable it for a bit.  That doesn't seem to be good enough for Windows 8.1.  I uninstalled the virus software and re-ran sql setup, complete with domain service accounts to success.  And, configuring folder exclusions for the C:\Windows\Temp folder in the virus program does not fix it either. 

The virus program does not behave that way in Windows 7.

I'm going to rebuild the O/S from scratch and re-install SQL, just to make sure all my monkeying around hasn't created a case where my premise is wrong.

I think I have it figured out.  It's the virus software (Avast).  That program normally doesn't get in the way of installation.  And, if I suspect it does, I just disable it for a bit.  That doesn't seem to be good enough for Windows 8.1.  I uninstalled the virus software and re-ran sql setup, complete with domain service accounts to success.  And, configuring folder exclusions for the C:\Windows\Temp folder in the virus program does not fix it either. 

The virus program does not behave that way in Windows 7.

I'm going to rebuild the O/S from scratch and re-install SQL, just to make sure all my monkeying around hasn't created a case where my premise is wrong.

• Marked as answer by Greg Wilkerson Wednesday, April 01, 2015 2:55 PM
• Unmarked as answer by Greg Wilkerson 12 hours 39 minutes ago

I think I have it figured out.  It's the virus software (Avast).  That program normally doesn't get in the way of installation.  And, if I suspect it does, I just disable it for a bit.  That doesn't seem to be good enough for Windows 8.1.  I uninstalled the virus software and re-ran sql setup, complete with domain service accounts to success.  And, configuring folder exclusions for the C:\Windows\Temp folder in the virus program does not fix it either. 

The virus program does not behave that way in Windows 7.

I'm going to rebuild the O/S from scratch and re-install SQL, just to make sure all my monkeying around hasn't created a case where my premise is wrong.

• Marked as answer by Greg Wilkerson Wednesday, April 01, 2015 2:55 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:26 PM

I think I have it figured out.  It's the virus software (Avast).  That program normally doesn't get in the way of installation.  And, if I suspect it does, I just disable it for a bit.  That doesn't seem to be good enough for Windows 8.1.  I uninstalled the virus software and re-ran sql setup, complete with domain service accounts to success.  And, configuring folder exclusions for the C:\Windows\Temp folder in the virus program does not fix it either. 

The virus program does not behave that way in Windows 7.

I'm going to rebuild the O/S from scratch and re-install SQL, just to make sure all my monkeying around hasn't created a case where my premise is wrong.

• Marked as answer by Greg Wilkerson Wednesday, April 01, 2015 2:55 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:26 PM

I think I have it figured out.  It's the virus software (Avast).  That program normally doesn't get in the way of installation.  And, if I suspect it does, I just disable it for a bit.  That doesn't seem to be good enough for Windows 8.1.  I uninstalled the virus software and re-ran sql setup, complete with domain service accounts to success.  And, configuring folder exclusions for the C:\Windows\Temp folder in the virus program does not fix it either. 

The virus program does not behave that way in Windows 7.

I'm going to rebuild the O/S from scratch and re-install SQL, just to make sure all my monkeying around hasn't created a case where my premise is wrong.

• Marked as answer by Greg Wilkerson Wednesday, April 01, 2015 2:55 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:26 PM

Thank you so much. I had the similar issue. Remove Avast and it worked !

• Marked as answer by Greg Wilkerson 12 hours 33 minutes ago
• Unmarked as answer by Greg Wilkerson 12 hours 33 minutes ago

Thank you so much. I had the similar issue. Remove Avast and it worked !

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:31 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:32 PM

Thank you so much. I had the similar issue. Remove Avast and it worked !

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:31 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:32 PM

Thank you so much. I had the similar issue. Remove Avast and it worked !

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:31 PM
• Unmarked as answer by Greg Wilkerson Friday, April 03, 2015 6:32 PM

A final update.

I posted something on the Avast forums and got back a response that explains/solves the issue.  Avast has a self-defense module that locks down permissions on the C:\Windows\Temp folder.  It may lock down other folders, but I don't know that for sure.

This can be disabled.  Doing so allows the installation to complete without error.  To disable the Avast self-defence module:

Systray -> Right Click Avast -> Open Avast user interface -> Settings -> Troubleshooting -> Enable self-defense module.

Symantec does not cause the SQL installation to fail like Avast does. And, this problem does not happen on Windows 7.

• Marked as answer by Greg Wilkerson 12 hours 29 minutes ago

A final update.

I posted something on the Avast forums and got back a response that explains/solves the issue.  Avast has a self-defense module that locks down permissions on the C:\Windows\Temp folder.  It may lock down other folders, but I don't know that for sure.

This can be disabled.  Doing so allows the installation to complete without error.  To disable the Avast self-defence module:

Systray -> Right Click Avast -> Open Avast user interface -> Settings -> Troubleshooting -> Enable self-defense module.

Symantec does not cause the SQL installation to fail like Avast does. And, this problem does not happen on Windows 7.

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:36 PM

A final update.

I posted something on the Avast forums and got back a response that explains/solves the issue.  Avast has a self-defense module that locks down permissions on the C:\Windows\Temp folder.  It may lock down other folders, but I don't know that for sure.

This can be disabled.  Doing so allows the installation to complete without error.  To disable the Avast self-defence module:

Systray -> Right Click Avast -> Open Avast user interface -> Settings -> Troubleshooting -> Enable self-defense module.

Symantec does not cause the SQL installation to fail like Avast does. And, this problem does not happen on Windows 7.

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:36 PM

A final update.

I posted something on the Avast forums and got back a response that explains/solves the issue.  Avast has a self-defense module that locks down permissions on the C:\Windows\Temp folder.  It may lock down other folders, but I don't know that for sure.

This can be disabled.  Doing so allows the installation to complete without error.  To disable the Avast self-defence module:

Systray -> Right Click Avast -> Open Avast user interface -> Settings -> Troubleshooting -> Enable self-defense module.

Symantec does not cause the SQL installation to fail like Avast does. And, this problem does not happen on Windows 7.

• Marked as answer by Greg Wilkerson Friday, April 03, 2015 6:36 PM

This does also happen on windows 7, or at least it did for me anyway. disabling the avast defence module allows setup to complete. 

thanks for the solution ! :) 

It worked for me. Thank you. I've wasted some hours till I found the answer :)