The SharePoint Lounge

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….

SharePoint 2013 uses claims based authentication exclusively.  If you’ve brought over some sites over using the database attach method that didn’t use claims based authentication, you need to run this command first.  Otherwise users who were able to access the site previously won’t be able to access the site.

Convert-SPWebApplication -Identity <your site> -To Claims -RetainPermissions

 

If you don’t want to have a banner at the top of all your sites asking users to upgrade, you can hide it by using these commands:

Get-SPWebApplication | % { $_.UpgradeReminderDelay=365; $_.Update()}
Get-SPSite -Limit All -CompatibilityLevel 14 | % {$_.ExtendUpgradeReminderDate() }

These commands extend the upgrade delay time to 1 year from when you run the command and simulates a user clicking on the “Remind Me Later” link.

I like to keep the look of the Central Administration site in development different – very different, if possible; the theory being that before you make an important change you’ll realize that you’re not in test land anymore (or vice versa). I have no guarantees that this works, especially when you’re in full stress mode because something broke in production and you’re trying to figure out why. But that never happens, right?
Or maybe you just don’t like the plain white color that Central Administration comes with by default. In any case, by default, there is no option to change the theme of the Central Administration site. Fear not, the page to change the theme is there, it just isn’t shown. Just append this link to the theme chooser to your Central Administration URL:

/_layouts/themeweb.aspx

So if your Central Administration URL is http://sharepoint.contoso.com:1234/ you would use http://sharepoint.contoso.com:1234/_layouts/themeweb.aspx.
And now the difference between dev and production is night and day. Or whatever you want.

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….)