Fixing the ScriptResource.axd Errors 500 Internal Server Error

ASP.NET Ajax client-side framework (ScriptResource.axd) failed to load.
The status code returned from the server was: 500
Status: 50 The request is not supported
An unknown error occurred while processing the request on the server
asp.net ajax client-side framework failed to load
or

Greetings SharePoint geeks!

The problem
This post is purely created from a little peice of reality. I just experienced this issue myself in a SharePoint setup published externally thru TMG.

It is not entirely easy to troubleshoot, with quite a few components involved, however, I managed in the end and I will here also give you a few hints on how to go about t-shooting something like this.
Anyway, the circumstanses look like all or some of these:

– An internal SharePoint webserver (sp01)
– A TMG 2010 Server connected to the internal network and the internet, used for many more services than SharePoint
– A Web Application, CollabSite, published using a Firewall policy (from the SharePoint publishing wizard)
– A MySite Web Application also published using the same wizard but a separate policy.
– Both sites are configured to only use https/SSL with a certificate issues by an internal CA.
– An external DNS record pointing both URLs to the eexternal interface of the TMG server.
– Internal DNS records also Points to the external interface of the TMG

When connecting to the sites, mysite.domain.com or collabsite.domain.com from a client on the internet. The site prompts for authentication, the site loads…almost…a popup appears that states:

‘asp.net ajax client-side framework failed to load’

The dialogbox popup

Most of the site loads, you see the blue banner at the top but nothing more.
Reloading the site does not give you the popup again, but soads the site without any of the AJAX functionality, like the ribbon and buttons in the top right area. The ribbon will on some pages show up but it only shows the ‘working on it’ twirl instead of the tools/buttons you would expect.

I will here describe why this happens and how you fix it. But first, I will give you a short version…

Short version
1. SharePoint/IIS offers the ScriptResource.axd files in a compressed format
2. TMG cannot inspect compressed files unless Compression filter/http Compression is enabled
3. Enable the ‘Compression filter’ in TMG under the ‘System’ node
4. Apply, done!

Long version
First we look at what is requested and what is delivered. I use IEs built-in F12 Developer Toolbar, IE later than IE9 will have a Network tab and this allows you to trace the traffic. Same thing if you use Firebug/Fiddler or Wireshark, whatever is available. Browse to the failing site, press F12 and select the Network tab. Here you click on the ‘Start Capturing’ button

This causes IE to collect and show all traffic coming to and from the browser.

The two /ScriptResource GET statements are what fails. This is all that is needed to stop all AJAX functionality, now we know that it has to do with something we do not get down to the browser ok, but why is that, how do we fix it? We need more info to be able to answer those questions.
We can get a bit more info from IE still, select one of the GET lines and click on ‘Go to detailed view’ to see more about the issue.

We get some more info here but not really something that tells us what is going on.

I now tried the same thing from a client on the inside, I added an entry to the local hosts file and added the url and pointed it directly to the IP address of the SharePoint Web Server. With this setup the problem is gone. What this tells me is that the problem is most likely something to do with TMG and how that is configured. Lets take a look.
Logon to the TMG server, make sure that you have permissions to manage TMG.

Since the site at least loads, we have toi assume that https and the publishing in general works as expected. It can’t be all bad.
You will find the logs by clicking on ‘Logs and reports’ in the left pane on TMG.

First add a filter, it should include a filter for:
‘Log record type’ = Firewall or Web Rule
‘Log time’ = Live
‘Action’ != Connection status
‘URL’ contains collabsite (Something that will identify the traffic to your site)

Now, you need to start a Query.
Click on start Query, Then go to your browser with the failing site and refresh the site again.
This should give you something like this in the TMG log

You get a few more pieces of info, but still no real answer to what is wrong…now..it is time.
Now we give up and ask a friend like I did or Google/Bing up this blog post.
Apperantly, this is due to SharePoint ‘offering’ these scriptresource.axd files, which by the way are files that do not exist, they are virtual…anyway, the files are offered in a compressed form, and when TMG is not configured to use compression, it can’t handled files beeing offered in a compressed format, at least that is a more or less accurate explaination to the what happens.
To soolve the issue, yup, it is easy.

Note! DO not make any Changes to the TMG if it is used in production, most Changes made will or can affect the functionality of other applications than SharePoint. Do this when it fits.

In TMG, go to the system node in the leftpane

Locate the Filter named Compression Filter and right click, Enable. It has to be enabled in order for TMG to ‘undersdtand’ compressed files…

Now, make sure that the filer shows an enabled state

You might Think that the Compression filter is now enabled…but no. You have to apply the Changes to TMG first, do this by clicking on the Apply button

The Apply/Discard buttons show app after you have made any change to anything in TMG. Obviously, Discard does nothing and does a reset on all Changes you have made, Apply makes it real. The Changes are commited.

Now. You should be ok. Check again in the browser. To be 100% sure, Close the browser and start a new one, browse to the address and logon if you have to.
Click on F12, Networking, ‘StartCapturing’ and refresh the browser.

Now, as you can see, the ScriptResource.axd files load ok with a 200 back from IIS. Test functionality and you will see that you have full AJAX functionality restored!

Failed Connection Attempt
Log type: Web Proxy (Reverse)
Status: 50 The request is not supported.
Rule: Sharepoint
Source: External (10.0.0.10:5656)
Destination: Local Host (collab.internal.domain.com 10.0.0.2:443)
Request: GET http://sp01.domain.com/ScriptResource.axd?d=j1ZhaacmuTdtaXKJmCKiL5N9BhFaiHjoyTepROfiG-dsvaranCGsbhWSAJThJOqErvtnV3f3JK-eai_4uSJCTTsp5WYkDzemQHrfpRrKq-8pIRNncb_vHcHCmvp1E9WFzbrvgUHEnQm3_A6TBJte_EfSWNQReBfix-6dygtTl0aL7MpGhhWiHQWrWzz1Cixd0&t=6119e399
Filter information: Req ID: 1658eda1
Protocol: https
User: Anonymous

Allowed Connection SERVERNAME DATE
Log type: Web Proxy (Reverse)
Status: 200 OK.
Rule: Sharepoint
Source: External (10.0.0.10:5656)
Destination: Local Host (sp01.internal.domain.com 10.0.0.2:443)
Request: GET http://sp01.domain.com/ScriptResource.axd?d=NPjpKZ25gaaa-UUxeA8GUGfiRsyQ0pvhyH-cklhXQDb_uZT9hy-ZNDagl3Gq5QHfhXPAOU_Ngxhu5H5qxWSnmMDCX-IUhKwtH01F785ZmXZ82_V3aeC5wX4aXxARfov8ZzG-FFwXtesO2xApQUCazxU3-FfqQL1NCZqTLM2ttQQhILR1azFbosx9-RCON3JR0&t=6119e399
Filter information: Req ID: 0670e57f
Protocol: https
User: anonymous

References

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

Managing the Distributed Cache Service in SharePoint 2013

Managing the Distributed Cache Service in SharePoint 2013 using PowerShell

A true multipurpose tractor

Greetings SharePoint Campers!

This time I will just offer a brief cheat sheet for Distributed Cache operations using powershell, which is pretty much the only way you can configure and manage the service.
For some reason, the Distributed Cache seems to offer a lot of people grief, all from no functionality at all to extremely slow responsetimes on all pages loaded (see SharePoint 2013 page loads takes a very long time).

My best tip, the often working quick fix with a malfunctioning cache service, is to first try and stop and start it, then if its still failing, delete the service and add it back again. You should also from the start change the default service account from the farm account to a separate, maybe dedicated managed account.

Quick fix
1.
Stop the service
Start the service
2.
Delete the service
Create a new service
3.
Start checking the logfiles and do a proper t-shooting.

Remember that in a multiserver farm, the PowerShell commands will affect the server where the command has been executed, so make sure to be on the correct server Before runing the CMDlets.

Distributed Cache tasks listed in the following order:

Change the service account running the Distributed Cache
Graceful stop and deattach local server (No lost cache data)
Dettach local server from a cache cluster (Multiple Distributed Cache servers)
Reattach local server to a cache cluster (Multiple Distributed Cache servers)
Delete the service
Create a new service
Start the service on a server
Stop the service on a server
Check current Cache memory allocation
Change the Cache memory allocation
References

Change the service account running the Distributed Cache

It is recommended to use a SharePoint managed account for this service.
$spfarm = Get-SPFarm
$spcacheService = $spfarm.Services | where {$_.Name -eq “AppFabricCachingService”}
$spaccount = Get-SPManagedAccount -Identity domain\spdistcache
$spcacheService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
$spcacheService.ProcessIdentity.ManagedAccount = $spaccount
$spcacheService.ProcessIdentity.Update()
$spcacheService.ProcessIdentity.Deploy()

CurrentIdentityType = “SpecificUser” should be just that and nothing else, do not replace this value

Verify by going to Central administration, Security, Configure Service accounts, Select ‘Windows Service – Distributed Chache’ i dropdown, that the service account has been replaced.

Graceful stop and deattach local server (No lost cache data)

Stop-SPDistributedCacheServiceInstance -Graceful
Remove-SPDistributedCacheServiceInstance

Deattach local server from a cache cluster (Multiple Distributed Cache servers)

Remove-SPDistributedCacheServiceInstance

Reattach local server to a cache cluster (Multiple Distributed Cache servers)

Add-SPDistributedCacheServiceInstance

Delete the service

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService”
$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.delete()

Verify in Central Admin, System Settings, Manage Services on Server. It should be gone from this list when it has been completely deleted.
In a multi server farm, you will have to select which server to show the services from in the top-right dropdown.

Create a new service

Add-SPDistributedCacheServiceInstance

Verify in Central Admin, System Settings, Manage Services on Server. It should appear in this list when it has been created. In a multi server farm, you will have to select which server to show the services from in the top-right dropdown.

Start the service on a server

Stop the service on a server

$instanceName =”SPDistributedCacheService Name=AppFabricCachingService” $serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Unprovision()

Check current Cache memory allocation

Use-CacheCluster Get-AFCacheHostConfiguration -ComputerName $env:computername -CachePort “22233”

Change the Cache memory allocation

On all Cache servers in the farm stop the service
$instanceName =”SPDistributedCacheService Name=AppFabricCachingService” $serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Unprovision()
Update the memory allocation
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize
Start the service on all Cache servers
$instanceName =”SPDistributedCacheService Name=AppFabricCachingService” $serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.Provision()

CacheSize is the cache size’s memory allocation assignment in MB

‘

Note: Beware of the signle and double quotes if you copy the code…

‘

References

Manage the Distributed Cache service in SharePoint Server 2013
http://technet.microsoft.com/en-us/library/jj219613.aspx

Plan and use the Distributed Cache service in SharePoint Server 2013 (Poster)
http://www.microsoft.com/en-us/download/confirmation.aspx?id=35557

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

SharePoint Security – State of the Union

SharePoint Security – State of the Union

A call to action regarding SharePoint and Security

Citizens of SharePoint!
I would like to say a little something about SharePoint and Security.
The usual focus when talking about IT and Security is technical aspects of security, it is a global phenomenon and it has always been like that. My most private thinking on the reasons for this is, that technical solutions simply are a lot more fun than the boring processes and policies. Take a Windows laptop for example, when discussing security it always comes down to Bit locker instead of discussing how you work to be secure.
SharePoint is no different, but in the SharePoint industry I feel that we have taken it even further, we do not even feel that Security is that much fun, or even that important maybe, the SharePoint community feels that custom solutions and architectural designs, maybe even corporate branding are a lot more fun than any aspect of Security.

Titanic, the unsinkable ship that sunk

In my personal opinion this is a shame and my hope is that this will gradually change in the future toward a more Security aware SharePoint community.
Developing new solutions, new custom applications and designing the world’s most elaborate SharePoint architecture will for a while yet I realize, be more interesting to the individual engineer than promoting the importance of keeping your local admin groups clean and why you should not logon using the farm account, for the most experienced Certified Master same as for the SharePoint IT-Pro beginner.
This is a fact and the risk is that we will start to see downsides from this as SharePoint for real has by now, found its rightful place in most every company’s infrastructure, all over the world.
Now you are probably starting to wonder how I can be so bold to state these things unfounded and without proof? You are probably thinking that you yourself is not like that, you do care about Security and all this is just about everyone else, if even that. Maybe some of us are better and some are worse, but we can all do better.
I have a feeling and I have some proof:
– I have for a while now worked dedicated with SharePoint Security, reviewing existing SharePoint environments and designing and implementing fresh new environments. During this period I have yet to come by a Security aware design of a SharePoint environment (my own designs excluded obviously).
– I have customers that have come to me and stated that part of the reason that they have contacted me, is that there simply is no other partner that focuses on SharePoint and Security and that can offer the services that I do. I am according to my customer, without competition, at least in my part of the world.
– I have seen from the SharePoint conference participant surveys, that of all of the topics that the participants want to hear more about next year, Security is always at the very bottom of the list.
– The number one rated and watched session at TechEd this year, was about hacker tools…

I may be wrong but I doubt it, security is not really on our agenda.
In my experience, all of us in this larger and larger SharePoint community, should pay a little extra attention on Security in all that we do. Not only in the Security technical aspects that we implement because we have to, take for example Kerberos authentication (Link to guide). Kerberos is a great Security feature that will enhance the Security in most SharePoint environments, but not many implementations have been made for the Security aspects of it, but for the simple reason that a double-hop scenario required it and thus it was implemented (visit my blog for an easy step by step guide to Kerberos in SharePoint).
Also, many, many SharePoint environments out there are setup by developers, I beg your pardon developers, but your focus is often to get a working test and development platform up and running, not to make it secure and stable. Also, after a solution has been developed and tested for functionality, your job is often done. The result is often something that is less than perfect in terms of Security.

It would be really nice if we could all help to change this, if we could all do just a few things that will in fact make the SharePoint environment more secure or at least, make it harder to penetrate and easier to keep track of.

I have made a list of things that we could all easily think of and do, and that would help SharePoint Security awareness.

Keep the number of local server administrators down to a minimum (0).

In most SharePoint environments we can assume that a local server administrator can get access to all of the content in SharePoint. Use domain groups, add an individual’s user account only as needed and remove when he/she is done.
You’ll find a command at the end that will show you a course list of the members of the local administrators group.

Do not disable the Loopback check on your Web servers.

This is a great Security feature, it will make life a little harder on a possible intruder, so why disable it. Add the URLs you need instead. If you buy a house and it has an alarm installed, you do not disable it, you grant access to the members of your family. Also worth mentioning, you should always avoid browsing from the server, but some features like search may depend on accessing the local server so a configuration may be the best answer.
You’ll find a PowerShell script at the end how you can easily configure it to allow the URL’s you need instead of disabling it completely.

Disable the SQL authentication and especially the SA account.

These account are completely unmanaged and unmonitored, it is a popular backdoor for any hacker.
They are rarely used and when used often by legacy applications, if they are, find out why and reconfigure or put the legacy app on a separate instance or server.

Never use Shared accounts (Never ever!).

I still see people defending the ‘setup account’ (shared installation and configuration user) and they state that it is given special permissions that are required later on. Operations people with a lot of people coming and going often use a ‘server monitor’ account that can be borrowed and used to get easy and fast access to the server. It is often a local account and often has a password that is well known by all…
In my opinion, there is never or very rarely a reason to keep a shared account. If you absolutely feel that you must, use a domain account and more importantly, disable it when it is not used. Also, change the password regularly.

Keep the Windows Firewall On (Ports-Link/Conf-Link).

Need I even explain this? It is however a sad fact that it is often disabled even in a production environment. It should be used and on in all environments, the development environment would else make an easy target for the evil hacker.
Configure it even during development, there are many ways to do it, PowerShell may be the simplest, check my blog blksthl.com on how to.
If you don’t do it right away, you or your customer will most likely forget to enable and configure it when you are done.

Keep the IE ESC On – Internet Explorer Enhanced Security Configuration.

A server is not really meant for us to browse SharePoint sites or the internet, use a client machine or a separate test server if you have to. If you MUST browse from this particular SharePoint server, disable it for admins only and enable it when done.
You’ll find a PowerShell script at the end how you can easily configure it.

Use HTTPS on Central Administration site.

Often, too often, https is used for web applications bt usually not for the central administration site, it is a bit of configuring and thinking to get it working, but it is a recommended way to protect your Environment. Remember, passwords will at times be transfered in cleartext on the central admin site.
Follow the Word of Spencer Harbar to get it done:
Using SSL for Central Administration with SharePoint 2013
http://www.harbar.net/archive/2013/02/13/Using-SSL-for-Central-Administration-with-SharePoint-2013.aspx

***

Summary,
My hope is, that we will all try do something extra when it comes to Security in the future, do your best to leave a better more secure environment behind, take a while instructing the customer on the importance of keeping the environment secure even after you have left. Make them aware as well.
If you or your customers need a wakeup call, please watch my dear colleague’s session from TechEd North America this year voted no 1, Marcus Murray and Hasain Alshakarti at Truesec:
Live Demonstration: Hacker Tools You Should Know and Worry About
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/ATC-B309#fbid=SxGCyIja7i5
After you or your customer has seen what can be done with simple tools avalable to all…perhaps the general attitude towards security processes may improve a bit?

Final word: It is not all about cool buzzwords/technologies like oauth or claims or federations, it is even more about processes and boring policies…

Configure Loopbackcheck (Link) In a PowerShell prompt running as administrator: Get-Item -path ”HKLM:\System\CurrentControlSet\Control\Lsa\MSV1_0” | new-Itemproperty -Name “BackConnectionHostNames” -Value (“coolsite.corp.balkestahl.se”, “alias.corp.balkestahl.se”) -PropertyType “MultiString” (Replace mine with your own URL’s and add more using double quotes and a comma and space as separator) Make the changes stick with: Restart-Service IISADMIN

Configure IE ESC (Link) In a PowerShell prompt running as administrator: function Disable-IEESC { $AdminKey = “HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}” Set-ItemProperty -Path $AdminKey -Name “IsInstalled” -Value 0 Stop-Process -Name Explorer } Disable-IEESC (You have to hit enter twice after pasting the script)

Crude list of all members of Local Administrators In a PowerShell prompt running as administrator: Gwmi win32_groupuser | where-object {$_.groupcomponent –like ‘*”Administrators”‘} | ft partcomponent There are better looking examples out there but this is a one-liner that does the trick…

References:

DisableLoopbackCheck & SharePoint: What every admin and developer should know. (Spencer Harbar folks)
http://www.harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx

A quick guide to configuring the Loopback check
https://blog.blksthl.com/2013/05/07/a-quick-guide-to-configuring-the-loopback-check/

Configure automatic password change in SharePoint 2013 using PowerShell
https://blog.blksthl.com/2013/05/14/configure-automatic-password-change-in-sharepoint-2013-using-powershell/

TCP/IP Ports of SharePoint 2013
https://blog.blksthl.com/2013/02/21/tcpip-ports-of-sharepoint-2013/

A guide to https and Secure Sockets Layer in SharePoint 2013
https://blog.blksthl.com/2012/12/20/a-guide-to-https-and-secure-sockets-layer-in-sharepoint-2013/

How to disable IE Enhanced Security in Windows Server 2012
https://blog.blksthl.com/2012/11/28/how-to-disable-ie-enhanced-security-in-windows-server-2012/

The first Kerberos guide for SharePoint 2013 technicians
https://blog.blksthl.com/2012/09/26/the-first-kerberos-guide-for-sharepoint-2013-technicians/

Using SSL for Central Administration with SharePoint 2013
http://www.harbar.net/archive/2013/02/13/Using-SSL-for-Central-Administration-with-SharePoint-2013.aspx

Thanks to:

Hasain Alshakarti – TrueSec
Marcus Murray – TrueSec
TrueSec Sweden / TrueSec US
Spencer Harbar – harbar.net
Andrija Marcic – Microsoft

___________________________________________________________________________________________________

Consider?

Regards

Twitter | Technet Profile | LinkedIn

Configure automatic password change in SharePoint 2013 using PowerShell

SharePoint fellas!

I have a new tip for you.
My very best SharePoint buddy asked me today how to configure the Automatic password change using PowerShell, he could not find an answer anywhere…it was a good question…seems like the answer was missing and that was when I started to do some research.
I found nothing! Could be that I missed something, but Technet, Blogs, Forums, none had the answer…

The impressive Engine of a Boeing 787 – Dreamliner

After a lot of testing and failing, I managed to produce this working script:

*Must be executed in a PowerShell prompt running as administrator.
*If used in a .ps1 script file, you have to set the execution policy first.
*Replace the domain\accountname with an existing managed account.
*Change the values to valid values that you want to use.

# Set Automatic password change schedule

$SPManagedAccount = Get-SPManagedAccount -Identity “domain\accountname”

#Create a SPMonthlySchedule object and set default properties (as in the gui)
$SPSchedule = new-object Microsoft.SharePoint.SPMonthlySchedule
$SPSchedule.BeginDay = 7
$SPSchedule.EndDay = 7
$SPSchedule.BeginHour = 2
$SPSchedule.EndHour = 3
$SPSchedule.BeginMinute = 0
$SPSchedule.EndMinute = 0
$SPSchedule.beginsecond = 0
$SPSchedule.endsecond = 0

# Set the change schedule on the account
$SPManagedAccount.ChangeSchedule = $SPSchedule
$SPManagedAccount.DaysBeforeExpiryToChange = 2

# Properties not enabled in a default scenario in the GUI
$SPManagedAccount.EnableEmailBeforePasswordChange = $False
$SPManagedAccount.DaysBeforeChangeToEmail = 2

# Enable and make the change
$SPManagedAccount.AutomaticChange = $True
$SPManagedAccount.Update()

Done!

In my environment, it looks like this:

After successfulle updating the Managed Account with the automatic update Schedule, I just typed in

$SPManagedAccount

and hit enter, that gives you the most common properties
If you want to see the entire Schedule with details, type in:

$SPManagedAccount | ft ChangeSchedule

Then you get this:

Thats it, a Schedule has been set!

If you want to use the GUI in central administration to find out what values to set, enable the Automatic Password change on any managed account, than set the values you want in the graphical user interface. Save them by clicking OK.
Next you run the following in your PowerShell prompt:
$SPTemplateManagedAccount = Get-SPManagedAccount “corp\sp10search”
$SPTemplateSchedule = $SPTemplateManagedAccount.ChangeSchedule
$SPTemplateSchedule
This will produce a list looking like this:
BeginDay    : 7
EndDay      : 7
Description : Monthly
BeginHour   : 2
EndHour     : 3
BeginMinute : 0
EndMinute   : 0
BeginSecond : 0
EndSecond   : 0
Use the values in the list in your script and you will have identical values set.

Note: If you want to have a Daily Schedule instead of Monthly like in my example, you will have to modify the script to create a Microsoft.SharePoint.SPDailySchedule object instead.
If you do that, you will also have to remove the lines setting the BeginDay and EndDay values, they are not used in a Daily Schedule object.

Good luck!

References:

Configure automatic password change in SharePoint 2013 (GUI version only)
http://technet.microsoft.com/en-us/library/ff724280.aspx

Plan automatic password change in SharePoint 2013
http://technet.microsoft.com/en-us/library/ff724278.aspx

Thanks to:

Mattias Gutke at CAG. He asked the question…

___________________________________________________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn

How to: Change the Distributed Cache Service managed account 2013

Hi friends.

When you get the annoying pink marker in CA and one of the issues it warns you about, is that ‘the farm account should not be used for other services’ In my case, the scripted install had set the ‘Distributed Cache Service (Windows Service)’ to use the farm account as managed account. As the 2013 Central Admin is (or tries to be) helpful, it gives you the direct link to the: ‘Security’ – ‘General Security’ – ‘Configure Service Accounts’ and tells you to change it there.

To fix it, just click the link, find the service in the dropdown and select another Managed account in the lower dropdown. Then click ok…..but nooo…that one wont fly.
Changing the service account on this service cannot be done this way and has to be done using PowerShell…thats what you get back.

Well…after some short researching I found this to work ok: (first load the snapin, add-pssnapin microsoft.sharepoint.powershell)

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq “AppFabricCachingService”}
$accnt = Get-SPManagedAccount -Identity <domain\user>
$cacheService.ProcessIdentity.CurrentIdentityType = “SpecificUser”
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()

(Where <domain\user> is the domain name and user name of the managed account you want to use instead.)

Note: Beware of the doublequotes if you copy the code…

Wait until it has run, then you will find that the service has a new managed account.
Go back to the Health Analyzer report page and remove the alert.

More on the Distributed Cache:
Manage the Distributed Cache service in SharePoint Server 2013
http://technet.microsoft.com/en-us/library/jj219613(v=office.15).aspx#changesvcacct

_________________________________________________________

Enjoy!

Regards

Twitter | Technet Profile | LinkedIn