Set Item level user permissions to add/edit/read only own items

In a recent project with SharePoint 2016, I needed to configure a library with the following user requirement: The users only have to view, their own items.

By default, this option it is not available in Library settings, it is only available for List settings, so… what we can do for a Library? You guessed right, PowerShell.

To do it, we can follow the following process:

You can also use s PowerShell script to manage the item level permissions:

Manage Read Access
$web = Get-SPWeb http://urlsite/
$list = $web.Lists[“Library Name”]
$list.ReadSecurity = 2
$list.Update()
$web.Dispose()

Note: 1 = “Read all items”, 2 = “Read items that were created by the user”

Manage Write Access
$web = Get-SPWeb http://url site/
$list = $web.Lists[“Library Name”]
$list.WriteSecurity = 2
$list.Update()
$web.Dispose()

Note: 1 = “Create and edit All items”, 2 = “Create items and edit items that were created by the user” 4 = “None”

Hope that helps!

Advertisement

File Shares as Content Source in SharePoint 2013 On Premises

Hi all!

Another quick post about file shares and SharePoint:

1. Identify your crawl account, because this account will be used to index the file share (unless specified differently with a crawl rule), so it is necessary to have read access to the file share to this account
2. If crawled files in file share system contain metadata, this will be used by the search refiners in SharePoint
3. Security trimming is respected, so when end users search the document in the search site, it will be displayed according to the permissions given on the files and folders.
4. Only metadata of the documents will be stored in SharePoint, not the documents
5. It is not possible to get a preview from Office documents that are stored in File Shares, to get a preview, you’ll need to use third party tools.

That’s all!

Run IISReset on All Servers in your farm at the same time

In case you have a large number of servers in a farm, the following script will help you to do a iisreset in all servers at the same time:

#Specify servers in an array variable
[array]$servers = “Server1″,”Server2″,….”

#Step through each server in the array and perform an IISRESET
foreach ($server in $servers)
{
Write-Host “Restarting IIS on server $server…”
IISRESET $server /noforce
Write-Host “IIS status for server $server”
IISRESET $server /status
}
Write-Host IIS has been restarted on all servers

Till next time!

Exceeding list view threshold

Hi folks,

Recently in a project where we need to work with large lists, as you will know, in SharePoint, lists with more than 5000 items causes problems to the users, and lists with more than 20k items are not possible to manage by the admins, in that cases you will receive a problem like:

“The view can not be displayed because it exceeds the list view threshold(5000 items) enforced be the administrator”

But if you look into the logs, you’ll see the following:

Microsoft.SharePoint.SPQueryThrottledException: The attempted operation is prohibited because it exceeds the list view threshold enforced by the administrator. —> System.Runtime.InteropServices.COMException: The attempted operation is prohibited because

In this case, it was a news list, so it was not possible to order the list in folders or any other method to avoid the item threshold limitation. What is the problem? This issue is By Design, so the throttling limit is enforced to protect the SharePoint Server, why? because each time we access to that list we make a SQL query as the number of items that this list has, so in case that this query exceeds 5000 items (by default) this action is avoided.

As you’ll know, it is possible to change this limit, but you’ll change this limit to the entire web app, which is not recommended, so why we can do as a workaround? Disable throttling 🙂 But you have to take into account that disabling throttling will cause performance issues on the SharePoint Server or the SQL Server.

$web= get-spweb “url”
$list=$web.lists[“listname”]
$list.enablethrottling = $false
$list.update()

After doing this, you’ll query more items in that list 🙂

hope that helps!

Managed Metadata terms not updating

We were working in a project where we had to working in a multicultural language, in this case we were using Spanish and English. The problem was that we had several metadata terms in the store, but only it were in one language (in Spanish), so we add more terms to have the English translation, but when we try to switch the language it always showed the terms in Spanish and not in English, so I had to discover what is happening.

First of all, I tried to run manually the job “Taxonomy Update Scheduler ” but it did nothing, so I tried to access to the Taxanomy Hidden list to see what was happening.

To those people who do not know how to access to the Taxonomy Hidden list, navigate to: [site url]/Lists/TaxonomyHiddenList/AllItems.aspx

The list by default has read access to all NTAuthenticated users. Make sure to verify this when your users have issues with using the metadata taxonomy service.

Also, the list contains only the taxonomy terms that were actually used anywhere in your site collections. That means when you are using a taxonomy term for the first time in any list, that term gets added as a new list item in the taxonomy hidden list.

This list contains the following fields to store the data about the taxonomy terms:

As you can see, it appears two time the same term in different languages (1033 and 3082), so the problem was there. There is a method to update the terms in the Taxanomy hidden list?

The answer is yes, and you guess it right the method is: PowerShell! So we need to execute the following code:

$siteurl=”yourappweburl”

Get-SPWebApplication $siteUrl | Get-SPSite -limit ALL | foreach {
[Microsoft.SharePoint.Taxonomy.TaxonomySession]::SyncHiddenList($_)

}

Once this code has been executed, we need to refresh the browser and access again to the same term, and voilà we have the terms updated.

If you want more info please refer the following links:

https://blogs.msdn.microsoft.com/kaushalendra/2012/10/16/how-to-sync-taxonomy-hidden-list-using-powershell/
https://prashobjp.wordpress.com/2013/09/30/updating-sharepoint-managed-metadata-term-hidden-value/
http://sharepoint-relieved.blogspot.com.es/2014/09/taxonomy-update-scheduler-not-working.html

Till the nex time!

CSOM The request message is too big while uploading attachment

If you are using SharePoint client Object Model and you need to change max size of the message you need to pass to Client.svc, what you probably need is to increase the default value. This can occour for example if you are uploading files to a remote SharePoint using client object model.

The message you are receiving when executing query with client obejct model should be something similar to this: “The request message is too big. The server does not allow messages larger than 2097152 bytes.”

The property is MaxReceivedMessageSize of ClientRequestServiceSettings.The default value is 2MB (2097152 bytes).

Use this PowerShell script (from SharePoint Management Shell in Administrative mode with a Farm Administrative Account) to change this value, in the example below we are changing this limit to 5Mb, also is it possible to increase this limit to 2Gb.

$ws = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$ws.ClientRequestServiceSettings.MaxReceivedMessageSize = 5242880
$ws.ClientRequestServiceSettings.MaxParseMessageSize = 5242880
$ws.Update()

If you want more information about this: https://msdn.microsoft.com/en-us/library/ff599489.aspx

Till the next time!!

Where is the miisclient??

Tons of times I have asked this question to myself, finally I was able to found it by doing a search in the drive letter, but I want to me more efficient 😛

So, if you are in same situation as me, you can find the 2010 and 2013 clients in the following locations:

MSS2010: C:Program FilesMicrosoft Office Servers14.0Synchronization ServiceUIShell

MSS2013: C:Program FilesMicrosoft Office Servers15.0Synchronization ServiceUIShell

Till the next time!

Request was rejected by the HTTP filter

Recenlty a client had published a SharePoint site through TMG.  Everything looked great until you went to view/edit the properties of a document in a document library.  I got the following error:

“Error Code: 500 Internal Server Error. The request was rejected by the HTTP filter. Contact the server administrator. (12217) ”

Trying the same actions on any other list/library worked fine; just not for a document library.

The problem turned out to be related to HTTP filtering in TMG.

To fix the issue, Open the properties of the firewall policy.  Click Filtering > Configure HTTPunder the Traffic tab.

Uncheck Verify normalization.

Save and apply changes and you should be all set.

But in case your problem is related with the people picker you should uncheck the value “Block high bit characters.”  This will fix the problem. This problem also happens when you publish the OWA urls thorugh TMG or ISA

Hope that helps!

AD account password out of sync with the managed service account within SharePoint

I guess that the following problem had happened to most of us, so I want to write down the solution I followed: The search service was throwing errors in the home, so I decided to enter to the server to see what was happening and I realized that the password for the managed account has expired. So, I tried to changed, but I received the following error:

The password for the account domusermss, as currently stored in SharePoint, is not the same as the current password for the account within Active Directory. To fix this with PowerShell, run Set-SPManagedAccount -UseExistingPassword.

So, the password for the account I am using to run the service using has been changed in AD, this does not match the password stored in the SharePoint.

One possible solution is to reset the password in the AD or the other solution is to use PS

Set-SPManagedAccount -identity “domusermss” -UseExistingPassword and enter the new credentials.

After that remember to change the password stored in the services of the server, if not will not be possible to start the services associated with the identity of this account.

Hope it helps!

SharePoint Add Site collection administrator

If you need to add user as a site collection administrator, you can use the following Powershell script:

param
(
[Parameter(Mandatory=$true, HelpMessage='username in format DOMAINusername')]
[string]$Username = "",
[Parameter(Mandatory=$true, HelpMessage='url for web application e.g. http://collab')]
[string]$WebApplicationUrl = ""

)

Write-Host "Setting up user $Username as site collection admin on all sitecollections in Web Application $WebApplicationUrl" -ForegroundColor White;
$webApplication = Get-SPWebApplication $WebApplicationUrl;

if($webApplication -ne $null)
{

foreach($siteCollection in $webApplication.Sites){
Write-Host "Setting up user $Username as site collection admin for $siteCollection" -ForegroundColor White;
$userToBeMadeSiteCollectionAdmin = $siteCollection.RootWeb.EnsureUser($Username);
if($userToBeMadeSiteCollectionAdmin.IsSiteAdmin -ne $true)
{
$userToBeMadeSiteCollectionAdmin.IsSiteAdmin = $true;
$userToBeMadeSiteCollectionAdmin.Update();
Write-Host "User is now site collection admin for $siteCollection" -ForegroundColor Green;
}
else
{
Write-Host "User is already site collection admin for $siteCollection" -ForegroundColor DarkYellow;
}

Write-Host "Current Site Collection Admins for site: " $siteCollection.Url " " $siteCollection.RootWeb.SiteAdministrators;
}
}
else
{
Write-Host "Could not find Web Application $WebApplicationUrl" -ForegroundColor Red;
}

To execute it, your user has to be site collection administrator, for me it was very useful, so…

Enjoy it!