Cant get siteowner for readonly sites

This is something I stumbled across recently… I wanted to retrieve a specific type of sites and their owners, when I checked the output of my script I figured that some sites seemed not to have siteowners, which irritated me a little. So I went to Central Admin checked the sites in the “View all sitecollections” area and found owners assigned to the sites. After fiddling around with PowerShell I figured out that if your site is set read-only you cant retrieve the siteowner anymore.

In the below PowerShell window you can see that I get a site and retrieve the owner from it. After that I set the site to be read-only, when I now retry to retrieve the owner I don’t get any information back. Once I set the read-only mode to false again the retrieval of the siteowner is working as expected.

I noticed this behavior in a SharePoint 2010 environment first and reproduced it in a SharePoint 2013 environment (from which I took the below screenshots).

If you look at the site in SharePoint 2013 you will be notified about the read-only status of your site.

In my special case I worked around it by retrieving the sitecollection administrators as I just needed somebody to contact but if you are really looking for that owner (or secondary owner) you might want to put a little bit more logic to your scripts to handle read-only sites.

“Database is up to date, but some sites are not completely upgraded” – and the journey to straighten things out

I faced an interesting thing in the SharePoint environments of one of my customers the other day…obviously the cool stuff never happens on your local environments .

This customer had patched their environment lately, everything was running smooth, nobody was complaining about anything, then, by incident, I checked the databasestatus.aspx page in central admin and found some databases marked with:

“Database is up to date, but some sites are not completely upgraded”.

So my first idea was, because they had a awful lot of databases in this state, to loop through all the databases and perform an upgrade-spcontentdatabase on the ones which contain not upgraded sites.

After running the script I found nothing changed on the UI (turns out if you do an IIS reset or an AppPool recycle this changes quite quickly). So after doing an IIS reset on the CA box I found some databases in the desired state “No action required” others though still in the same state.

So I checked the upgradestatus.aspx in the CA and found some warnings and errors for the databases containing sites which are not upgraded in the referenced upgrade logs. The most warnings I saw stated that

“Feature could not be upgraded. Exception: Unable to access web scoped feature (id: FeatureID) because it references a non-existent or broken web (id: webID) on site “siteurl”. Exception: System.ArgumentException: Value does not fall within the exptected range.”

When I checked the mentioned site and searched for the specific web I found this web existing in the recycle bin of the site.

So my next step was to create a PowerShell script to loop through all the sites and figure out which sites contain web objects in their recycle bin.

Once I have done that I created another PowerShell script removing all the webs from the recycle bin of the affected sites.

After that I ran my upgrade script again and found all databases in the “No action required” state except for two.

The first one was easy, this database was taken offline and for that couldn’t be upgraded.

For the second one I found Errors in the upgrade logs telling me:

Microsoft.SharePoint.Portal.Upgrade.MossSiteSequence failed.

Exception: Attempted to perform an unauthorized operation.                      

at Microsoft.SharePoint.SPSite.set_AllowDesigner(Boolean value)
   at Microsoft.SharePoint.Portal.Upgrade.AllowMasterPageEditingAction.Upgrade(SPSite site)
   at Microsoft.Office.Server.Upgrade.SiteAction.Upgrade()
   at Microsoft.SharePoint.Upgrade.SPActionSequence.Upgrade()

This confused me because I knew that my customer had SharePoint Designer disabled for this webapplication.

After some asking around it turned out this wasn’t always the case, they had it enabled for a short timeframe… So my assumption is one of their sitecollection administrators must have enabled SharePoint Designer on his or her site during that short timeframe and maybe even modified something with it… scary huh?

Now SharePoint Designer being disabled on webapplication level SharePoint seems to have a little problem with that when performing upgrade operations on this site.

To overcome this issue I enabled SharePoint Designer for the webapplication and rerun my upgrade script again and afterwards disabled the SharePoint Designer settings again on the webapp level. After that I had all databases in every SharePoint Admins favorite state “No action required”

Status list webpart continues to load…

Recently I was with a client and encountered some very interesting behaviour on one of their SharePoint 2010 sites.

Lets assume you have a list containing data and a status list which visualizes some of the data of the list in form of an graphical KPI, now you place a status list webpart on one of you pages displaying the information from your status list… everything works just fine. Unfortunately clients don’t call me in to show me how fine things are working…My client wanted to place a second (and even more) status list webparts on the same page and here is what they experienced:

The webpart which was placed last on the page will continue to show you the status bar instead of your beloved KPI.

After some investigation I found that my client was running on the December 2011 CU:

I reproduced this issue on my local environment after putting the February 2012 CU on the issue was fixed (I put February on on purpose to see how far back this issue has been fixed…)

Good2Know: Merge Terms…What does it do?

Today I played around with the SharePoint2010 managed metadata termstore and especially with the “merge terms” functionality.

What did I do:

1. I have created a termset “TestTermSet” (I know I am so creative when it comes down to names)

2.I have created Terms (Term1-Term4) within the termset

3. I have created a list “TermsTest” and added two managed metadata columns to it.

4 I have created two entries in that list (Test1 – Term2, Term3 / Tes3 – Term4)

I ran the following PowerShell to get me the IDs of the existing terms:

$taxsession = Get-SPTaxonomySession -Site http://yoururl
$termstore = $taxsession.termstores[“SharePoint – MMS”]
$testgroup =$termstore.groups[“Tests”]
$termset =$testgroup.termsets[“TestTermSet”]
foreach ($term in $termset.terms) {
   
    Write-Host $term.name “-“$term.id
}

 

The output was:

Term1 – 1280d6f8-3db8-42ec-87be-2ab9389e8d13
Term2 – c3cb39a5-5fcb-4040-90c7-005eb34b53f1
Term3 – 01bb9ed6-08e5-43dd-be03-9bbd17a45fd2
Term4 – 8fe913ef-6879-4003-b0e5-82ad9a358dfb

Then I merged (using the UI on central administration) Term1 and Term4:

After running the script again I get this result:

Term2 – c3cb39a5-5fcb-4040-90c7-005eb34b53f1
Term3 – 01bb9ed6-08e5-43dd-be03-9bbd17a45fd2
Term4 – 8fe913ef-6879-4003-b0e5-82ad9a358dfb

So Term1 disappeared, Term4 kept its ID and when you look into the UI you see that Term1 has been added as an “Label” (synonym) to Term4

When you now check the list with the entries made you will still find Term1 as value of one of the columns.

When you now create a new entry in your list and you enter “Term1” SharePoint will autosuggest you “Term4”.

So from what I can see the “Merge term” functionality just adds a new label to an term and removes the term. And as so often in SharePoint values set previous to the merge will not be updated after a merge… Interesting

Permissive mode in browser file handling

From time to time it happens that you want to open specific files directly from SharePoint and not want to download them… I know I know Microsoft files are working just fine but for example if you want to handle pdf documents.

For that you have a setting on the Centraladministration site:

CentralAdmin –> Application management –> Manage Webapplications –> General settings

Here you find the setting for the browser file handling.

 

You can set it to permissive and now you should be able to open the document directly.

If you want to set it for all your webapplications you can use this script:

Add-pssnapin "Microsoft.SharePoint.Powershell"
$webapps = Get-SPWebApplication
foreach ($webapp in $webapps)
{
    $webapp.BrowserFileHandling = "permissive"
    $webapp.Update()
}

 

BUT hold on… continue reading!!! There is more…

 

Setting the permissive mode could be a security risk and the better way to configure the aimed behavior is not to set it for just all applications (using permissive mode) but for specific applications using so called “Allowed Inline Downloaded Mime Types”.

You can use this script to set it for example for pdf documents:

Add-pssnapin "Microsoft.SharePoint.Powershell"
$webapps = Get-SPWebApplication
foreach ($webapp in $webapps)
{
    $webapp.AllowedInlineDownloadedMimeTypes.Add("application/pdf")
    $webapp.Update()
}

From my perspective this should be the way to go, until you really need to enable the permissive mode for an webapplication.

SharePoint2010 – Handling Alerts with Powershell

Alerts are a SharePoint functionality almost all of my clients use, to get an overview off all alerts of a specific sitecollection (for each user) your good friend PowerShell is an enormous help.

 

Get All Alerts from a sitecollection:

Get-SPweb -site http://yoursite -limit all | ForEach-Object {$_.alerts|foreach-object{write-host $_.user $_.properties["siteUrl"] $_.properties["dispformurl"]}}

 

If you do a migration of urls you want the url within your alerts to be changed as well of course, you can do this by using the following script for one or all sitecollection within your webapplication.

 

Update Alerts of one SiteCollection:

Get-SPweb -site http://yoursite -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://yoursite";$_.update()}}

 

Update Alerts for all SiteCollections:

get-spsite -limit all -WebApplication http://yoursite | get-spweb -limit all |ForEach-Object {$_.alerts|foreach-object{$_.properties["siteUrl"] = "http://yoursite";$_.update()}}

 

Please be aware that you run any scripts on your own risk, as always you should know what you are doing, don’t call me up crying and tell me you ran that script you weren’t sure about what it actually does and it burned down your environment.

Farm provisioning issues

During my work onsite with a client I faced an interesting issue which I think is worth mentioning here. After the SharePoint binary installation the SP2010 farm gots provisioned and we were about to join the other servers into the farm (connect them to the created configuration database). On one of the machines though we found a hotfix for a specific language pack missing. But somehow this server was joined the farm, on the “Servers in farm” site you could find a note that this server is missing an important update. The patching overview in the SharePoint central administration displayed the missing hotfix as well. So we downloaded the hotfix, installed it on the machine and thought about running the configuration wizzard to properly connect the server to the farm again. When it comes up to running the configuration wizard we encountered an error within the wizard telling us that the hotfix we just installed is not installed on the system. Our first approach was to reboot the machine and rerun the SharePoint configuration wizard again… Same result. Bummer!

Then I thought, ok we remove the server from the farm and join it back in again, removing a server from a SharePoint farm can be done in several different ways,

1. using the SharePoint configuration wizard… ehm, not in this case!
2. using the central admin
3. using good ol’ psconfig.exe
4. The way described below 🙂

Because number one was not applicable I removed the server from the farm using the central administration, but when running the SharePoint configuration wizard it still locked to be connected to the farm somehow and it failed running.

Because you cant trust the UI, I removed the server using psconfig.exe (psconfig -cmd configdb –disconnect), which told me that the server has successfully been removed from the farm. But when running the SharePoint configuration wizard the same issue occured and it failed out at the end.

So I said to myself: “Self…we have a problem here”, shortly before starting to cry and thinking about how to get out of the room and run away the SharePoint admins swiss army knife PowerShell came to my mind and I remembered an powershell cmdlet “Disconnect-SPConfigurationDatabase”. I ran the cmdlet and when firing up the SharePoint configuration wizard I now saw the option to join an existing farm or create a farm myself. I joined the server to the existing farm and… it worked just like a charm.

SharePoint2010 Powershell Commands Overview

get-command –pssnapin microsoft.sharepoint.powershell | format-list name, definition will return a overview of all SharePoint2010 Powershell commands.