Handle multiple versions of powershellPnp with Sharepoint

 This is a nice way to handle accessing different versions of PNPPowershell. 
I use this when switching between onpremise environments of different version and online.

Note that env-variables can't be used until session, like ISE is restarted. Otherwise can variable be accessed immediatly using 
[System.Environment]::GetEnvironmentVariable('SharePointPnPPowerShell2019','machine')

setupEnv.ps1 downloads named modules in $array to $saveFolder. 
Then locates psd1-file and adds this as a enviroment variable with name in arrayobject. 
To use the module access env-variable with $env:name as showed in importModule_Example.ps1

References:
https://www.erwinmcm.com/running-the-various-versions-of-pnp-powershell-side-by-side/

enumerate columns from subsites

This case is something which I've came back to a few times.
Customer wants to output columns from certain content types from a number of sites.
Its always a hassle to get the correct names of columns so I've built a method to output the values more dynamically.

1. First getFields.ps1 reads columns containg values from a list item, outputs to gridview, chosen values gets saved to customfields.csv
2. Second getSitecontenttypefields.ps1 enumerates all sites on chosen destination and loops all items of specified content types and outputs chosen fields from customfields.ps1 to an object which is saved to a csv-file.

Using hashtables to combine values

For a job I needed a good way of combining a primary value with optional subvalues in a xml-file.
Below is an example of how to extract attributes from a xmlelement into a hashtable and then join two hashtables into one. I couldn't find a method for extracting elements on the web, folks usually goes with subnodes instead of attributes. I'm partial to attributes and had to get creative, but the solution was quite simple. The Attributes from the element only show the actual elements from the xmlfile. Its not obvious when browsing the object that -name property can be lifted, but here it's used for creating a new hashtable-row



Samplescript for proof of concept


This eventually led to createwebsFromStructure.ps1 that uses powershell splatting to build commands with the resulting hashtable.

References:
https://powershell.org/2013/01/23/join-powershell-hash-tables/ - source for join-hashtable function
https://technet.microsoft.com/en-us/library/gg675931.aspx - source for details on splatting

Troubleshooting sharepoint alerts

Method for determining what happens with sharepoint alerts from the serverside.

1. To determined which server is sending the mail.
   (Note that this will be different for different webapps, so best is to monitor the whole farm with ULS)
   run Sysinternals procmon on all servers (usually only the frontends) monitor traffic for :25
2. Activate verbose logging for alerts
   
3. Monitor ULSViewer on specific member or the whole farm for events matching below
   Category contains "Alerts" AND Message contains "Alert for" OR Message contains "Successfully sent"
   
   

Now ULS messages will show successfull and failed (based on securityfiltering) sent emails.

References:
https://blogs.technet.microsoft.com/steve_chen/alerts-in-sharepoint-troubleshooting-mosswss/

http://sharepointalert.info/troubleshooting-sharepoint-alerts/

http://www.sharepointdiary.com/2012/02/sharepoint-alerts-not-working-troubleshooting-checklist.html

Patching Sharepoint with the homebrew-method

Patchning Sharepoint is not something to taken lightly.
It's a high risk not to patch but a guaranteed risk to apply the patches.

Last year I had a difficult experience when I patched a semilarge(7 members) farm for the first time with Cumulative Updates.
This had 5 webapplications and +200 databases. And it took some time. Like 30 hours, most of the time being lost when running psconfig on each host.
Supposedly, sharepoint should only upgrade the databases on the first member run, but something still takes a lot of time, even its only to check if upgrade is required.

So a more effective method was needed.
I looked into the impressive SPPatchify-project but found the results to be too inconsistent. Sometimes the script ran through it all and said everything was green, when actually two servers had failed psconfigs and a lot of other issues giving half-finished state.
So I deviced my own hybrid method using the best parts of the sppatchify-idea and russmax exe-installationscript.

The method took the installationwindow down to 4 hours in total, where only 2 hours was complete downtime.
Its a bit more manual than others, but therefore also gives more control.

The steps
Preperations

1. Take whole farm offline and take snapshots, or use regular backups. Whichever method you trust most.
2. Backup All databases

Installation

1. Stop all sharepointrelated-services
1.  For AppServers 1. App-Prepatching
2.  For Frontends  1. WFE-PrePatching
2. Run exe on all members
3. Start all services 
1. For AppServers 2. App-PostPatching
2. For frontends  2. WFE-PostPatching
4. Export all databasinformation to file.
1. ExportAllDbs.ps1
5. Dismount all databases (after making sure you have all correct info on file from previousStep) This will take everything offline.
1. DismountAllDbs.ps1
6. Run psconfig on all members starting with AppServers
1. RunPSConfig.ps1 on each member 
7. Mount all databases
1. MountAllDbs.ps1  - Update the filename to your exported databases
8. Upgrade databases in parallel. While each db is upgrading website on it will be unavailable. If you're sql supports it you can mitigate this using -usesnapshot  How many concurrent jobs is depending on hardware. I found the sweetspot to be 4 concurrent jobs, after that it started taking longer time that running them in sequence. But this might vary. 
1. UpgradeDatabasesFaster.ps1
9. Check on warnings in Health Analyzer, make repairs if needed. 
10. Make sure User Profile Synchronizer service is running (if your using FIM-sync)

Below all relevant scripts. Use at your own risk.



References:
https://blogs.msdn.microsoft.com/russmax/2013/04/01/why-sharepoint-2013-cumulative-update-takes-5-hours-to-install/ - Russmax excellent script for halting services before running exe. Saving hours
http://www.spjeff.com/2016/05/16/sppatchify-cu-patch-entire-farm-from-one-script/ - SpJeffs
https://blogs.technet.microsoft.com/stefan_gossner/2015/08/20/why-i-prefer-psconfigui-exe-over-psconfig-exe/ - Excellent resource for patching

Users break dispform

In this particular case a user decided to throw away the main webpart of the dispform.aspx. This caused all kinds of problems since it was a calenderlist.
In this situationen it wasn’t possible to create a new list since a lot of coded things worked with listids. Theres no versioning of dispform.
I first tried to use restore to sitedefinitions, but this kind of change didn’t qualify for making restore for some reason.
So this what came instead.

1. Find a functioning “vanilla” dispform.aspx from a list of same type
2. Open Sharepoint Designer, goto website of above list, find list and copy ListID
3. Find dispform of functioning list and export to file. Save locally on computer
4. Open locally saved dispform with notepad. Find and replace listid of sourcelist with targetlist listID (in calenderar two matches)
5. Opensharepint Designer, goto website of broken list.
6. All Files>Lists><mylist>
7. Take a backup of dispform with export to file, just in case you mess up.
8. Import locally modified dispform
9. Changes take effect immediatly.

References:
https://support.microsoft.com/en-hk/help/2000858/listview-webpart-required-on-dispform.aspx-page-for-document-library

Finding duplicate content types

Got to a chance to build a script for finding content type duplicates in a Site Collection

#Description:Find duplicate content types in sitecollection

Add-PSSnapin microsoft.sharepoint.powershell

$siteURL = "https://test-mysite.mycompany.com"
$site = get-spsite $siteURL
$object = @()

foreach ($newWeb in $site.AllWebs) {
    foreach ($cType in $newWeb.contentTypes) {
        $tempObj = new-object PSObject -Property @{webURL=$newWeb.Url; CTName=$cType.Name; CTid=$cType.Id}
        $object += $tempObj
        }
    }
#sort out duplicates
$duplicates = $object |Group-Object ctid |Where-Object {$_.count -gt 1} |select -ExpandProperty group

write-output "Found $($object.count) content types in $siteURL"
write-output "Total duplicates: $($duplicates.count)"
$duplicates

Urlrewrite and sharepoint 2013

I some trouble recently getting urlrewrite to play along with SP2013 and IIS 8.
HostNamedSiteCollection wasn’t doable for a lot of other reasons.
Scenario: Using urlrewrites to handle vanityurls for site collections in SP2007. When migrating to SP2013 these rules don’t work at all.

Symptoms:

• With outboundrules activated nothing works for webapplication. (Website cannot display the page) 
• Always lands on top site collection, rewrite dont work.

Solution:
A combination of a few fixes

• Install patch kb2749660 to fix outboundrules
• Add registry key ("HKLM:\Software\Microsoft\InetStp\Rewrite\" (Dword) LogRewrittenUrlEnabled=0)
• Deactivate Static Compression on IIS-site
• Add rewrite rule like {HTTP_HOST} matches pattern ^www.labb13.nu(.*)

References:
https://support.microsoft.com/en-us/kb/2749660 - Response is corrupted when you configure an outgoing rule in URL Rewrite Module 2.0 for IIS 7.0 or IIS 7.5
http://ruslany.net/2010/05/storing-url-rewrite-mappings-in-a-separate-file/
https://blogs.msdn.microsoft.com/danielvl/2010/01/07/registry-values-for-iis-url-rewrite/
http://stackoverflow.com/questions/14607390/iis-urlrewrite-is-not-working-for-iis-8
http://social.technet.microsoft.com/wiki/contents/articles/23074.sharepoint-2013-url-rewrite.aspx
http://blogs.technet.com/b/mspfe/archive/2013/11/27/how-to-create-a-url-alias-using-iis-url-rewrite.aspx – example (without sharepoint)
http://johnliu.net/blog/2010/7/23/sharepoint-2010-with-iis-url-rewrite-20.html
https://www.iis.net/learn/extensions/url-rewrite-module/creating-outbound-rules-for-url-rewrite-module
https://social.technet.microsoft.com/Forums/en-US/8d076df4-d93c-47be-80cc-f22dddc1c4c8/how-to-implement-url-rewriting-for-sharepoint?forum=sharepointdevelopmentprevious – similar problem. http://blog.mastykarz.nl/friendly-urls-sharepoint-site-4-steps-iis7-url-rewrite-module/ - rewrite with sharepoint 2013
http://blogs.msdn.com/b/chiranth/archive/2014/06/13/url-rewrite-part-3-outbound-rules-amp-rewrite-maps.aspx - why use outbound rules?
https://support.microsoft.com/sv-se/kb/2818415 - supported assymentrical solutions

Script to check databases upgrade status

Ever wonder how the upgrade is doing?
This script checks the status of all Sharepoint-databases.

 

Add-PSSnapin microsoft.sharepoint.powershell

 

$alldatabases  = get-spdatabase

write-output "Status for all databases"

$alldatabases |Sort-Object needsupgrade |select name,webapplication, canupgrade,needsupgrade |format-table -autosize

write-output "Databases needs upgrade: $(($alldatabases |where-object {$_.needsupgrade -like "true"}).count)"

write-output "Timestamp: $(get-date -format "yyyy-MM-dd.HH:mm")"

List installed Sp2013 updates

Get list of installed updates for Sharepoint 2013.
If languagepacks are installed these parentdisplaynames will need to be added with –or

#settings#
$myfilename = "InstalledHotFixes.htm"
#settings end
$outputfile = "$(split-path -Parent $myinvocation.MyCommand.Definition)\$myfilename"

$items = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*
$spitems = $items |where-object {$_.parentdisplayname -like "Microsoft Sharepoint Server 2013"}
$spitems |select displayname,installdate,urlinfoabout,parentdisplayname |format-table -AutoSize
$spitems |select displayname,installdate,urlinfoabout,parentdisplayname | ConvertTo-html|Out-File $outputfile

write-output "Total patches: $($spitems.count)"
Invoke-Expression $outputfile

References:
http://blogs.technet.com/b/heyscriptingguy/archive/2013/11/15/use-powershell-to-find-installed-software.aspx

Disturbed Cache

The Scenario
Sharepoint 2013 developed publishing site using adfs. AppFabric with CU5.
The problem
In a developed Sharepoint Site we were seeing a lot of strange issues.
Sometimes some requests weren’t finished, some things might not get loaded.

The troubleshooting
It was very hard to troubleshoot since there wasn’t any patterns to the errors initially.
In an attempt mitigate the issue we raised the cookie-length for the adfssessions from default 60min to 720.
This gave us even more issues, now the frequency of the errors were more often. While navigating for 10min an issue usually occurred twice.
When monitoring the connections with fiddler while browsing we noticed a lot of requests going to the adfs-server. When really it should only happens twice a day.
I ran a search for errors in the ULS log for same period and noticed some errors relating to tokens
Common errors were:
Token Cache: reverting to local cache to add the token….
Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage ‘DistributedLogonTokenCache’…. Request time out
And some others in dump below

Now obviously I’ve tangled with the cache before so it's really no surprise the nasty distributed cache is involved in this mess.

Ok, so now we’ve learned that timeouts occur on Distributed Caches Logon Token Cache. Who do we fix it?
Luckily the error message actually contains a part of the solution. Blablabla … MaxBuffersize must be greater or equal….
To actually find these errors I used my LogSearcher

To check servers timeout-settings


The solution
1. Increase timeouts on DistributedLogonTokenCache and items on SecurityTokenServiceconfig

2. Stop all distributed cache services gracefully
Stop-SPDistributedCacheServiceInstance -graceful
Make sure to wait 5-10 minutes between first cache restart to the last. This so the cache actually have time to reconnect to the cachecluster and make friends with other caches. Note that cache need to be restarted from Manage Services after above command.
3. Run IISreset on all hosts.

Conclusions
These errors started occurring pretty might day one in the environment. Though it was when users actually started using the site as the problem became apparent.
The SecurityTokenServiceConfig doesn’t seem to be used the same way when using Windows Authentication. This made it impossible for the developers to troubleshoot in their environment without having their own adfs-solution.
Now a part of the problem was solved only by increasing cacheitems,channelopentimeout and requesttimeout. I would say that these settings solved the exceptions and fails.
While maxbuffersize and maxbufferpoolsize solved the Failed to add/get token errors below

First part I assume was due to the many API-connections that happened on the starter pages, big page with ajax-loading a lot of the components with rest. These might have maxed out the ItemsCache or it was due to the fact that tokens didn’t get saved in the cache properly or couldn’t be acquired in time.
Second part too many claims at a time, big or improperly formatted.
But Im just guessing here.

References:https://social.msdn.microsoft.com/Forums/en-US/e13871ce-5b6f-4a3c-bc04-fbce47870856/sharepoint-web-app-randomly-gives-302-redirect-to-reauthenticate-even-with-valid-fedauth-cookie?forum=sharepointgeneralprevious
https://habaneroconsulting.com/insights/sharepoint-2013-distributed-cache-bug
https://technet.microsoft.com/en-us/library/jj219613.aspx#finetune
https://danielthenerd.wordpress.com/2015/05/08/comprehensive-distributed-cache-and-security-token-service-config-review-for-sharepoint-2013/

Newsfeed acting up

When mounting a production mysite to a dev-environment I got some exciting problems with the newsfeedpage.

Symtoms:
Posting new items worked fine. No errors, but when trying to comment other users threads following errors was dropped in our laps

Using the excellent Microsoft error translater I got this
Svenskt: Detta kunde inte posta eftersom vi har lite problem för tillfället.
English: This couldn't be posted because we're having some issues at the moment.
Same time this event 8306 shows in eventlog on server

After some digging in the ULS-logs I found this
STS Call Claims Saml: Problem getting output claims identity. Exception: 'System.InvalidOperationException: GetUserProfileByPropertyValue: Multiple User Profiles
Ok, so maybe profile problem. I check my profiledb and fine there is two profiles for my account since Im using both claims and windows in my testenvironment. I remove the one not used and try to reply to a post again.
I’m awarded with a new error

So now we’re getting somewhere!
Translating stupid swedish server…
Svenska: Det gick inte att kontrollera rekursionen.
English: Recursion check failed.

Found excellent post which solved by problems.
So I trow away my FeedIdentifier for my troubled users and re-access mysite using said user  and now It works!

Solution:
Update FeedIdentifier for problem users by deleting value for Feed Service Provider Defined Identifer and login on users mysite to recreate.
Its also possible to recreate string using new mysites siteID. Code on post below.

Conclusion:
Mysites are not to thrown around easily Especially between farms, even if they are in the same domain. All sites are have unique siteids. Had we also restored the user profile service we probably wouldn’t have this issue, but then that is a whole lot extra work. Therefore I now empty this Feed Identifiers with scripts when attaching mysites from production for selected users to make everything shine.

References:
https://social.technet.microsoft.com/forums/sharepoint/en-US/26031f27-491b-4fb9-8b81-88ca5e9ce474/like-button-doesnt-always-work – solution and extra code for fix
https://www.microsoft.com/Language/en-US/Emt.aspx – localized error messages

User Profile Service –what I learned so far

Sharepoint huh? It’s never easy.

I’ve been looking hard at User Profile Service lately for a variety of reasons, this is what I’ve learned. Use caution and test locally before using these, there’s always the risk of wiping the mysitedb. But if site hasn’t been heavily used, whats there to loose.

So how does it all come together? These are our key players:

Component	Description
Sharepoint Profile Synchronization	Uses Forefront Identity Manager for syncing AD. The Old solution, the syncdb often messes things up. Though it’s the only solution if you need to write changes to AD, like profile pictures.
Sharepoint Active Directory Import	Uses Dirsync to import AD. Fast but can only read.
User Profile Service Application	Handles all our specifics. This Service can be recreated and still keep the information if databases if these are not deleted.
User Profile Service Synchronization Service	This Server Service must be running to make changes in the UPSA. When it runs, it creates local certificates that muddies the local certificate store. If the service is stubborn, the local certificates may be removed, they will be recreated.
Microsoft Forefront Synchronization Manager	C:\Program Files\Microsoft Office Servers\15.0\Synchronization Service\UIShell\miisclient.exe – This software is useful for determining whats goes wrong with the AD-connection. Its only accessible after you actually got UPSA running. You can use Metaverse Search to verify the AD-changes are coming through the connection.
Timerjob User Profile Service Application ProfSync	Also known as User Profile to Sharepoint Full Synchronization Job – This handles the sync from the ProfilesDB to the Site Collections User information list. Runs every hour per default.
Timerjob User Profile Service Application_Sweepsync	This handles sync from profilesdb to site collections User information list incrementellay. Runs every five minutes per default.
Timerjob My Site Cleanup Job	This handles deletion of profiles marked for deletion. Usually when profiles are removed from User Profile Service. It also removes obsolete user. Mysites that are assigned to deleted user is assigned to their manager and notification is sent

Problem/symtom: User Profile Synchronization Service stuck on starting. Without it, no AD-connection can be created.
Common Solutions: - Verify service is running with spfarm-account
- Verify spfarm is local administrator on AppServer
- Stop Service and try to start again.
$ups = get-spserviceinstance |where-object {$_.typename -like "User Profile Synchronization Service" -and $_.server -like "*$env:computername*"}
$ups |select id,typename,status,server
Stop-SPServiceInstance -Identity $ups.Id -Confirm:$false
- Remove all ForefrontIdentityManager certificates from local certificate store and services Forefront Identity Manager Service and Synchronization Service.


These will be recreated each time the service restarts.
- Empty farmcache.
          - Stop TimerService on localserver,
           - delete all files except cache.ini in C:\ProgramData\Microsoft\SharePoint\Config\ {guid}(folder containing cache.ini)
          - Change cache.ini to value 1
           - start TimerService

Problem/symtom: Something is off with the running sync. For example, changes in AD not replicating, when they have done so before.
Common Solution: Recreate User Profile Service Application
- Gather all information you need to recreate the service,
- Databasenames
- Permissions for User Profile Service (Centadmin>Manage User Profiles>People>Manage User Permissions)
- Administrators on User Profile Service Application(UPSA), Permissions on UPSA
- Special permissions levels, Site Naming format, Security Trimming Options on My Site Settings in UPSA
- Active Directory Synchronization Connections (OU, accounts for connecting), Synchronization settings
When recreating UPSA with old databases, the SyncDB have to be removed manually or use a new name. The SyncDB is staging area between ProfileDB and FIM-AD-Sync. Basicly whay miis looks into to see how it all went. SocialDB contains all likes and social functions.  
Symptoms: Cant access the User Profile Service Application. Correlation id shows : This User Profile Application's connection is currently not available. The Application Pool or User Profile Service may not have been started.
Common Solution:
- Restart or start User Profile Service and User profile Synchronization Service. Order: stop UPS, then UPSS, start UPS then UPSS.

- Recreate proxy for Service Application and make sure proxy is connected to Default Proxy group or whatever group is used.
$proxy = get-spserviceapplicationproxy | Where-Object {$_.typename -eq "User Profile Service Application Proxy"}
$newproxyname = $proxy.name
write-host "Removing proxy..."
Remove-SPServiceApplicationProxy -Identity $proxy -Confirm:$false
$upa = get-spserviceapplication |Where-Object {$_.typename -eq "User Profile Service Application"}
write-host "Adding proxy..."
$newproxy = New-SPProfileServiceApplicationProxy -name "User Profile Service Application" -Uri $upa.uri.AbsoluteUri
$defaultproxygroup = Get-SPServiceApplicationProxyGroup -Default
Add-SPServiceApplicationProxyGroupMember -Identity $defaultproxygroup -Member $newproxy


Problem/symptom: Users are not syncing from AD or SyncDB to profiledb
- Checking FIM Sync from C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe shows that sync is working from the AD to SyncDB
- Checking ContentDBs shows sync is occurring between ProfileDB to UserLists
foreach($db in Get-SPContentDatabase){$db.Name+" - "+$db.LastProfileSyncTime} - Checking Timerjobs shows sync is running
$TimerFullSync = get-sptimerjob | where-object {$_.name -eq "User Profile Service Application_ProfSync"}
$TimerQuickSync = get-sptimerjob | where-object {$_.name -eq "User Profile Service Application_SweepSync"}
$TimerFullSync,$timerQuickSync |select name,Jobdisplayname,lastruntime,description |format-table -wrap
Common Solution:- Kill Connection and restart sync – This is useful when User Profile Service and Site Collections don’t update properly. These should get updated with User Profile to Sharepoint Full Sync and QuickSync. Check with Listoldatabase first to see if time seems old.
set-location "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN"
#stsadm.exe -o sync -listolddatabases 0
stsadm.exe -o sync -deleteolddatabases 0
$TimerFullSync = get-sptimerjob | where-object {$_.name -eq "User Profile Service Application_ProfSync"}
$TimerFullSync.RunNow()

References:
https://technet.microsoft.com/en-us/library/ff681014.aspx -
https://technet.microsoft.com/en-us/hh296982.aspx - permissions for sync
http://blogs.msdn.com/b/kaevans/archive/2012/06/25/top-recommendations-for-managing-the-my-site-cleanup-timer-job.aspx

Problems with updating feeds

Issue when running Update-SPRepopulateMicroblogFeedCache on Sharepoint 2013.

Add-PSSnapin microsoft.sharepoint.powershell
$accountname = "mydomain\spinstall"
$appProxy = Get-SPServiceApplicationProxy | where {$_.typename -eq "User profile service application Proxy"}
#$appProxy |format-table -AutoSize
Update-SPRepopulateMicroblogLMTCache -ProfileServiceApplicationProxy $appProxy
sleep -Seconds 30
Update-SPRepopulateMicroblogFeedCache -ProfileServiceApplicationProxy $appProxy -AccountName $accountname

Got this puppy:

When checking permissions on UPS with:

$USPA = Get-SpServiceapplication | Where-Object {$_.TypeName -eq "User Profile Service Application"}
$sec = Get-SPServiceApplicationSecurity $USPA
$sec.AccessRules

I noticed my spinstall account missing.
Added with nice found code

$USPA = Get-SpServiceapplication | Where-Object {$_.TypeName -eq "User Profile Service Application"}
$sec = Get-SPServiceApplicationSecurity $USPA
$account = New-SPClaimsPrincipal "mydomain\spinstall" -IdentityType WindowsSamAccountName
$sec = Get-SPServiceApplicationSecurity $USPA
Grant-SPObjectSecurity $sec -Principal $account -Rights "Full Control"
Set-SPServiceApplicationSecurity -Identity $USPA -ObjectSecurity $sec

Finally the repopulate cmdlet ran successfully.

Note though, this should really only be necessary if mysite has been restored or remounted (like earlier version). Possible if Distributed Cache has been shutdown ungracefully.

References:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/8becf279-4889-4f0f-aa7a-428bc9a813f8/user-profile-service-access-denied-issues?forum=sharepointadmin
https://technet.microsoft.com/en-us/library/jj219560.aspx
https://technet.microsoft.com/en-us/library/jj219700.aspx

Exclude checkin comments

I had a request to hide checkin comments from searchresults in Sharepoint 2013. I decided to hide the column from the index.

This can be done from UI

1. Central Administration>Search Service>Search Schema > Crawled Properties> Ows__checkinComment
2. Uncheck Include in full-text index
3. Full crawl

Or with powershell
------setCrawlPropCheckInComments.ps1-----

Add-PSSnapin microsoft.sharepoint.powershell
$name = "ows__CheckinComment"

$searchapp = get-spenterprisesearchserviceapplication

$crawledprop = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Name $name
$crawledprop.IsMappedToContents = $false
$crawledprop.update()
----------------eof--------------------------------------------
And full crawl

-----------startFullCrawlOnAllContents.ps1----------------
Add-PSSnapin microsoft.sharepoint.powershell

$contents = get-spenterprisesearchcrawlcontentsource -SearchApplication "Search Service Application"

foreach ($content in $contents)
{
if ($content.crawlstatus -eq "Idle")
{
write-host "Idle, running crawl on $($content.name)"
$content.StartFullCrawl()
}
else {write-host "$($content.name) is not idle or on nogo-list" }

}
----------------------------eof--------------------------------------

One thing to keep in mind is if CheckInComments column is visible on any Views on the site, that view will be returned in results.

References:
http://www.synergyonline.com/Blog/Lists/Posts/Post.aspx?ID=242 
https://social.technet.microsoft.com/Forums/en-US/66c87e10-2e27-46e3-b176-27706f8e2fda/exclude-content-from-search-hithightlight-results?forum=sharepointgeneralprevious

Versioning in Sharepoint

What happens with versions when restored in an list?

If this is the starting position:

Version 4.1 is the latest minor version that also is published. When we restore version 3.0 what happens is this:

Version 3.0 is copied as version 4.2 and is now the current version.
If we change our mind and decide that wasn’t a good one, we can restore previous version 4.1 to get back our starting position.

Results may vary depending on if minor/major versons enabled.

If we want to compare versions when working with documents, we do this from within word itself under Info>Manage versions

Upload files to library

Simple script to upload all files from specific folder to documentlibrary.

 

$path = "C:\myfiles\TestDocs";

$user = "mydomain\john.doe"

$pass= "mysecretpassword"

$destination = "https://mysite.mycompany.com/mylib";

 

 

$securePasssword = ConvertTo-SecureString $pass -AsPlainText -Force;

$credentials = New-Object System.Management.Automation.PSCredential ($user, $securePasssword);

#$credentials = [System.Net.CredentialCache]::DefaultCredentials;

 

$webclient = New-Object System.Net.WebClient;

$webclient.Credentials = $credentials;

 

Get-ChildItem $path | Where-Object {$_.Length -gt 0} | ForEach-Object { $webclient.UploadFile($destination + "/" + $_.Name, "PUT", $_.FullName)};

 

xls tries to open with excel services when searching

Scenario:
I had an issue with excel documents trying to open with Excel Service when using search. Although Excel Services wasn’t even configured on the Sharepoint Server.
When looking at the Site level, feature for always open with clientprogram was activated. Same thing at the list-level, Server default was activated.
Workaround Solution:
When searching, check for preferences at the bottom


Activate Open in the browser. This will probably only solve for the current user, but if in a tight spot.

Retrieve latest timerjobs

To get a quick overview over latest timerruns and get rid of scrolling endlessly in Central Admin
-----getTimerJobHistories.ps1--------
Add-PSSnapin microsoft.sharepoint.powershell
$number= 10 #total results
$timername = "User Profile Service Application_LMTRepopulationJob"
$timerjob = Get-SPTimerJob $timername
$timerjob.HistoryEntries | select jobdefinitiontitle,starttime,endtime,status,errormessage -first $number|format-table
#$timerjob.HistoryEntries
------------eof---------------------

Overall steps to move from Active Directory to ADFS authentication in Sharepoint 2013

This is for birds-eye perspective. I found it difficult to find resources that outlined the procedure. This omits everything that happens on the ADFS-server and focuses on sharepoint-parts.

1. Backup all contentdatabases, take snapshots of servers
2. Add relying party identifiers on ADFS-server. Add endpoints with ws_federation for all web applications that are going to use ADFS.
3. Add identity provider on sharepointserver (PS1.ConfigSPIdentifier)
4. Activate wsreply on sharepointserver
5. Add Identity provider to relevant web applications
Authentication Provider > Claims Authentication Types > Trusted Identity Provider
6. Configure new User Profiler Synchronization, use Authentication Provider type = Trusted Claims > your adfs
Configure User properties >
email = mail
Claim User Identifier = mail
Run full sync
7. Convert all users on webapplications. Don’t convert searchaccounts, don’t convert authenticated users. Change it to for example domain users
Use move-spuser
8. Change SuperUser and Super Reader accounts to adfs
Run change cachereaders on each webbapp and change accounts on User Policy on webapps.
9. Change loginpage for ADFS (optional, but enables automatic signin for directory users) (also enabled crawl to run as AD-user)
Copy autologin.aspx to common files\template….
Change in autologin.aspx to use current ADFS-provider
Change CentralAdministration> authpolicy > default signin page = autologin.aspx
10. Check search engine so everything works.
11. Install LDAPCP to solve peoplepicker issues.
12. Hide AD from selectionlist
13. Done.

Issues that occurred:
Couldn’t view any others mysites – solution add / permissions for all users.

Otherwise it worked quite nicely. 6000+ plus users migrated. This solution used email as primary claim. This then required the email field in AD to be populated with unique value.

Do I need to say that I take no responsbility for when this goes sideways? I don’t. But it worked for me.

PS1.ConfigSPIdentifier

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\xss\ADFS-Token-Signing.cer")

New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "upn" -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

$realm = "urn:test-intranet:sharepoint"

$ap = New-SPTrustedIdentityTokenIssuer -Name "TEST_ADFS@contoso.com" -Description "STS-IP id1.contoso.com" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3 -SignInUrl "https://id1.contoso.com/adfs/ls" -IdentifierClaim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

PS2.Activatewsreply

$tit = Get-SPTrustedIdentityTokenIssuer fs.contoso.com
$tit.UseWReplyParameter = $true
$tit.Update()

PS6.HideADfromLookup
$cpm = Get-SPClaimProviderManager
$ad = get-spclaimprovider -identity "AD"
$ad.IsVisible = $false
$cpm.Update()

References:
http://blogs.msdn.com/b/scicoria/archive/2011/06/10/sharepoint-2010-fba-and-sliding-sessions.aspx - Explains sliding sessions
http://msdn.microsoft.com/en-us/library/hh446526.aspx - explains adfs token
http://msdn.microsoft.com/en-us/library/office/hh147183%28v=office.14%29.aspx
http://blog.robgarrett.com/2013/05/06/sharepoint-authentication-and-session-management/ – good information on authentication process
http://www.wictorwilen.se/sharepoint-2013-with-saml-claims-and-sharepoint-hosted-apps – wsreply
http://weblogs.asp.net/wesleybakker/adfs-sharepoint-2013-single-sign-on-skip-authentication-provider-selection-page - ADFS Sharepoint 2013 Skip authentication Provider Page – autologin.aspx