Category: SharePoint 2010

Changing service account credentials in SharePoint is always an adventure. You never know whether something’s going to go wrong, leading to an afternoon’s worth of searching for expired credentials, updating them, and hoping that’s the last one. So you can imagine how I felt when I found out that one of our SharePoint instances wasn’t working because the employee who had set it up using his own account (one of those rookie mistakes, I suppose) had left. His account had naturally been disabled and so the SharePoint timer service couldn’t run. Because the farm administrator’s account was disabled Central Administration couldn’t be used to change any managed account credentials as it is inaccessible along with the other SharePoint sites.

In cases like this it is necessary to go back to the days of our friend STSADM. Yes, even though Microsoft has been moving towards PowerShell for many SharePoint command line operations, changing farm credentials is not one of them. On the primary SharePoint (Central Administration) server, run:

stsadm –o updatefarmcredentials –userlogin <DOMAIN\username> –password <password>

On all the other servers in the farm, run:

stsadm –o updatefarmcredentials –userlogin <DOMAIN\username> –password <password> -local

Make sure the “-local” switch is included, otherwise the update commands will conflict.

As is often the case with SharePoint, an iisreset /noforce is necessary.

Now that the farm account was taken care of, it was time to determine what else was broken. Since we now had access to Central Administration it was now possible to change most accounts via Security > Configure Service Accounts. However, attempting to change the Distributed Cache account will lead to the following error message:


Sorry, something went wrong
Distributed Cache Service does not support this operation from Central Administration. Please use Sharepoint Powershell commandlets.


(Ah, Microsoft…one minute you want me to use STSADM and another you want me to use PowerShell…)

Googling this error leads to the following blog post:
https://technet.microsoft.com/en-us/library/jj219613.aspx

There’s a section on this page – Change the Service Account – which tells you what needs to be done, with one exception: the script provided doesn’t have line breaks!

Here is the proper script:

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


Run this command as a PowerShell administrator and your Distributed Cache should be back up and running. At least until you discover those other services running under that same account….

In some instances, you may deploy a SharePoint environment which is in two different domains and want the SharePoint instance to be able to recognize logins from both domains. This is in fact possible, as long as at least one of the domains has a one way trust with the other domain.

What isn’t obvious is that you can’t do this from the web interface: you do it from the command prompt.

via http://www.pointbeyond.com/2012/06/08/sharepoint-2010-and-one-way-trusts-it-works-fine and other articles, you need to first create an application password:

stsadm –o setapppassword –password <password>

Then, you can add the new forests/domains via:

stsadm –o setproperty –url <url> –pn peoplepicker-searchadforests –pv "domain:<primarydomain>;domain:<secondary>,<domainb>\<serviceaccountusername>,<serviceaccountpassword>"

where is the URL of the web application you want users to be able to access from both domains. The is the domain on which you’ve setup SharePoint (hence the omission of the service account names and passwords).

Proper security practices dictate that passwords should be changed periodically. Unfortunately, for an application like SharePoint, this can also be a major headache.  Since SharePoint 2010, the application has the ability to change passwords automatically on a weekly or monthly schedule, so you don’t have to worry about that account that expired yesterday.  This feature can be accessed from the Central Administration > Security > Configure managed accounts page: for the account that you would like the password to be changed automatically, click on the Edit button and select the appropriate option.  Once the options are set, SharePoint will automatically change the password for that account at the preset time, and update the passwords on services that use that account as appropriate.

This is all well and fine if the password change is successful.  But what if it fails?

It depends on when in the process the failure occurred.  If it failed during the password change you’ll have to figure out what the new password is and update and restart any service that hasn’t been updated yet.  More on that one of these days.

If it failed before the password change, then you may find that your “Configure Managed Accounts” page is broken. Navigating to the page will cause an error.
In this case, you’ll have to disable automatic password changes on that account via the SharePoint PowerShell.

$ma=Get-SPManagedAccount -Identity “\”
$ma
$ma.AutomaticChange=$false
$ma.Update()
$ma

You should now see that automatic password changes have been disabled for this account.  The manage account page should then show up again, which will allow you to retry the process again.

Of course, you could always do it the old fashioned way….

We had a site where opening a document’s information panel (Document Properties) would result in a message similar to the following:

“The Document Information Panel was unable to load.  The document will continue to open.  For more information, contact your system administrator.  Document Information Panel cannot open the form.  To fix this problem, contact your system administrator. Form template: infopath:empty The XML Schema for the form template has an invalid value for the following attribute: location”

From scouring the web, the “Form template” portion of the error can vary, though the root cause is usually the same: a bad InfoPath document.  In some cases, this is caused by copying a template from another site.  It appears that SharePoint has a bug where the copy is incomplete:

http://wss.boman.biz/Lists/Posts/Post.aspx?ID=82

In other cases, the Document Information Panel has a bad InfoPath form template.  You can edit the templates by going to the document library’s settings page, clicking on the problem content type’s page, then clicking on “Document Information Panel settings.”  You’ll need InfoPath to edit the templates.

Got an interesting problem when I came in today. A user had two SharePoint subsites within the same site collection. After choosing “Read-Only” after clicking on a PDF document in a document library, the user would be presented with the option to “Open” or “Save” the file in one site; on the other, there was no “Open” option.

At the root of this is one of SharePoint 2010’s new security features. Browser File Handling is a property that can be set at the Web Application level, and requires that certain files be downloaded to the user’s computer instead of opened inside the browser. By default, this setting is enabled (set to “Strict”). Setting this permission to “Permissive” will allow files to be opened inside the browser (the default behavior for SharePoint 2007). More information on Web Application general settings can be found here:

http://technet.microsoft.com/en-us/library/cc262107.aspx

However, this was already the setting on the web application being used, and there is no site-collection/site specific setting. So what gives?

As it turns out, sites that have been migrated from SharePoint 2007 may not necessarily respect the “Strict”/”Permissive” settings. While newly created document libraries will adhere to the web application’s settings, some existing libraries may need to be manually updated. The blog post here provides information on how to fix it.

http://nerdtastictips.blogspot.com/2010/08/sp2010-forces-users-to-save-pdfs.html

Notice that the post’s author uses a check on the document library’s title for the word “Document.” If not all of your document libraries are named as such, you can use this code instead, which looks for the Document type instead and changes all of the site’s libraries (that are of type Document, anyway).

foreach ($list in $rsrWeb.Lists) { if($list.basetype -match "Document") { if($list.browserfilehandling -eq "Strict") { $list.browserfilehandling = "Permissive"; $list.update(); $site.url, $list.title, $list.browserfilehandling} } }

So, the full procedure to fix this goes as follows:

1. Start the SharePoint 2010 Management Shell.
2. Link the $site variable to the site collection.
   $site = Get-SPSite("<site>")
3. Open the site.
   $web = $site.OpenWeb()
4. Open a document library on the list.
   $list = $web.GetList("http://mysubsitecollectionurl/List");
5. Change the browserfilehandling property.
   $list.browserfilehandling="Permissive"
6. Optionally, change the property on all lists in this subsite.
   foreach ($list in $rsrWeb.Lists) { if($list.basetype -match "Document") { if($list.browserfilehandling -eq "Strict") { $list.browserfilehandling = "Permissive"; $list.update(); $site.url, $list.title, $list.browserfilehandling} } }

Note that you will need to start from step 1 again if you are working on multiple sites – during the process the $site variable will get linked to the subsite.

We started getting this error on our SharePoint server. One of those once-every-minute type errors that leaves you looking at a sea of red when you look at the event log in the morning.

Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (<GUID>).

Reason: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by <USER>, in the OWSTIMER (4272) process, on machine <MACHINE>. View the tracing log for more information about the conflict.

Technical Support Details:
Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SearchDataAccessServiceInstance was updated by <USER>, in the OWSTIMER (4272) process, on machine <MACHINE>. View the tracing log for more information about the conflict.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

This is a single server farm SharePoint instance that was recently rebooted, so perhaps something went wrong on the shutdown/reboot process. Restarting it again unfortunately did not help. Happily, this one was easily resolved through a Google search.

You need to clear the SharePoint user cache, which can be found at %ALLUSERSPROFILE%\Microsoft\SharePoint\Config\. Delete all the files here, then create a cache.ini file (this may be automatically created after you delete everything, at least it was for me). Edit the file using Notepad/your favorite text editor and add the number 1 to the file.

Your error should then clear up :).

You may have to stop/start the SharePoint services that are running, but I didn’t have to.

See another post about this here: http://behof.wordpress.com/2011/06/20/application-server-job-failed-for-service-instance-searchserviceinstance-spupdatedconcurrencyexception/

(Seeing as this was posted a few days ago maybe there’s something about June that triggers this….)

This is another migration related issue. If you’ve migrated from a Microsoft Office SharePoint Server instance to the free Foundation 2010 product, users may not be able to create new document libraries without another “unexpected error” occurring. This is because the site is still referencing workflows, such as the Approval Workflow, that are not provided with the free product. For what it’s worth, the document library is created, it’s just disconcerting to users when they seen an error message.

To resolve this, you can of course pay Microsoft for the paid product (don’t forget the user licenses!). Or, you could remove the workflows from the site. Get yourself a copy of SharePoint Designer 2010 (free!) and open the site. Navigate to the Content Types pane (on the left hand side), then open the Document content type. Delete each of the workflows there, and document libraries will no longer generate errors when they are created.

If you’ve migrated a SharePoint site from an older version of SharePoint (such as Portal) to 2010, you may run into this issue: links that you had linking to Documents and Lists, Site Settings, etc., they may break. Instead of going to the expected page, you get an error indicating that “An unexpected error has occurred.”

This is because the 1033 directory no longer works. So

/_layouts/1033/viewlsts.aspx

leads to the error. To fix it, change the link to

/_layouts/viewlsts.aspx

instead.