Category: SharePoint

Posted on

SharePoint Site Slow Load

So I finish up another SharePoint 2010 -> 2016 migration and after themeing and everything is put in place, the next day my dev tells me he notices the sites slow. So I run a couple pages and sure enough each page takes 20-25 seconds to load.

Here’s a Snippet of the network console of a site that works normally. Full Site Load in almost under a second.

Not sure what was going on since the test commands were 100% clean before hand and tested this a couple times in a test, followed all my documentation to a tee.

Here’s the snippet of the slow loading SharePoint. *Note I updated this Blog post cause I came across this issue again with a newly created SharePoint Site.

As you can see over 10x slower. Trust me, you feel this…

Checking the logs showed error messages of the SharePoint Managed account failing to access the User Profile Database. (Ohhh bad me, I should be a bit more specific, I found these lines of errors in the ULS Logs (%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\16\Logs)

Checking the permissions set for the managed account in the database (the instance and database name are dependent on your particular SharePoint installation) sure enough showed no access rights, when all other managed services accounts had basic connect rights.

Under security I found the security principal of the service account and under it’s User Mappings I added the DB_Access right for the managed service account. Sure enough this cleared the error message from the SharePoint logs and sites were loading super last. Always check your logs…

Posted on

SharePoint Orphaned
Content Types (ReportServer)

New Series! SharePoint Orphaned!

The only thing that should be orphaned, is SharePoint itself…. ohhh ouch,

The Story

joking aside, our Developer again came by reporting some issues with the newly developed SharePoint site I had migrated for him to test creating some new SharePoint web part apps. He already had his own documentation available when he first did this, good man. Even after we got past the “how to create a new template from a site with publishing features enabled”, we were still receiving an error.

Slow SharePoint fixed… But…

During this whole process this new site was intermittently responding slowly, it was baffling, and as we dug through the UNLS logs we found the issue, apparently the service account configured to run the Web Application Pool did not get access to the ProfileDB for some reason, after granting the login SPAccess on the ProfileDB it fixed the slow intermittent SharePoint loads… but sadly we were still receiving errors while attempting to deploy new sites from templates.

The signs were clear

Looking further in the UNLS logs, and the error itself complaining that content types could not contain special characters…. A bit more searching pointed us towards the sites content types page….

Whooops how did I miss this… (ReportServer Feature…)

Guess there are the “special characters”….. ugh, even though the “Test-SPContentDatabase cmdlet” returned clean throughout my migration (and all my scripts I have yet to publish). Guess this one isn’t picked up by the checker? unno anyway… what to do about this…

The search

Source one… too complicated, but interesting… he sure worked hard, I’d go this route, but I’m sure there are easier solutions… got to be and… yup.

Source two simple… lets try it…

The Solution

Install the feature, disable it on all web apps deployed on the farm, uninsatall the feature. Nice and simple, and how I usually like it, letting the system do most of the heavy lifting to avoid human error.

So Step 1: Grab Reporting Service installers (my case SharePoint 2016)

Step 2: Install it;

Next, Accept the EULA, Install

Success.

This makes the content type names behave correctly.

Step 3: Enable it;

Install-SPFeature -Path "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\FEATURES\ReportServer"

Now the original post said to simply Uninstall it after, but as you can see it will error, why cause, as it clearly states it’s still enabled so…

Step 4: Disable the feature on all web applications

Disable-SPFeature –Identity ReportServer –Url http://spsite.domain.com

Step 5: Uninstall the Feature:

Uninstall-SPFeature -Identity e8389ec7-70fd-4179-a1c4-6fcb4342d7a0

Step 6: Uninstall the package:

msiexec /uninstall rsSharePoint.msi

I recommend to do this after hours and on a test first. It did seem to do a IISRESET as all sites had to reload, and took a lil bit for the .NET assemblies to recompile. 😀

Now go enjoy a coffee. Thx, Jussi Palo!

The Second Solution

OK, not gonna lie, I assumed it was all good, and that assumption came to bite me in the ass…. again, never assume.

So I told my dev that I had completed the steps and should have no issues creating a new site from his template, but as I’m walking down the hall a short time later, he give me the snap fingers (like it worked) and says, “same error”.

Ughhhhh… what…

So looking back at the Sites Content Types the Report Model Document content type still remained… ok what the….

So running through the proceedure again, it cmplained stating the feature was not available for my web apps, so I re-enabled it, saw all three content types, disabled it… and report model still there…. :@ c’mon! Let’s just delete the content type!

Can never give me a break eh SharePoint…

Luckily my dev is super awesome and told me about another blog he had read (sorry I don’t have the source) and told me that the only reason the front end actually refuses to let you delete the content type, isn’t so much that it’s tied to an actual feature (even though we all know that this one did come from the ReportServer feature), but rather that it simply has a flag set on it in the table for it…

Now I normally never recommend making changes on any SharePoint Database stuff directly, and usually always recommend making all required changes via either the Central Admin/psconfig, site settings or PowerShell. However in this case we clearly installed the proper dependencies, de-activated the feature that populates those content types yet was not being removed from the content databases…

Only do this if you have tried everything else, only do this in a test environment, actually never do this…. well I guess if you have tried everything else this is your only option…

This requires you to have syadmin rights on the SQL Server instance hosting the SharePoint Content Databases. Open SSMS…

SELECT *
FROM WSS_CONTENTDB.[dbo].ContentTypes
WHERE Definition LIKE '%Report%'

Find the row which contains the ID for the Report Builder Content Type (Or which ever other system based content type you have orphaned needs removing). usually easily spotted as it’ll be the only one with 1 under

USE WSS_CONTENTDB
Go
UPDATE dbo.ContentTypes
SET IsFromFeature = 0
WHERE ContentTypeID = *ID From above Query*

Now you can go into the actual orphaned Content Type under Site Settings and watch the delete content type not fail or error, and destroy that content type from your SharePoint life!

*Note* My Dev came back saying same error again, lol, but this time it was discovered we simply had to re-create the template and deploying the template from new worked (which originally didn’t before the above changes)

Happy SharePointing!

Posted on

SharePoint Rest API call returns 500.50 URL rewrite error

The Story

Hey all another SharePoint Story here!

So my dev was working on another SharePoint site app. We did everything like before, and now he was getting a URL rewrite error. I wasn’t sure why this was happening, and since he generally had more experience troubleshooting these types of issues I sort of let him handle it for a while.

Well after a while he still couldn’t figure it out, and funny thing happened, we learned some interesting things and got bit by erroneous error messages in the end. So the first thing he tried was to give his re-write rules some new variable names. Which didn’t help and the same error was returned.

After a little while I had forgot to set the Service Principal Names (SPNs) for the new web applications we created for the new SharePoint sites. I was certain this was it, but we kept getting a URL rewrite error! (This turns out was actually the initial reason for the error, yeah it really was cause it turns out…)

I showed by dev this post by Scott on the same error. Now the reason we were getting the same URL rewrite error was cause when he changed the variable names in his re-write rule he didn’t change their associated server variables as mentioned in Scotts blog.

The Answer

The only reason we got the error both times was simply a coincidence. So it turns out:

1) If you forget to set the SPN when you Web App is set for Kerberos, and your hosting app server is on another server. You will get a re-write error if you have everything else in place.

2) If you change variables in your re-write rule and forget to set the associated system variables with it.

Both will result in a 500.50 URL rewrite error… who would of figured…

Posted on

SharePoint – Invalid Field Name

The Story

Today was an interesting day, I was getting my morning coffee with dock and video cables in hand as I was about to help a colleague with a video issue when my developer walked in.

I could tell something was up when he walked in as he had a bit of a “catch his breathe” feel in his persona as he went about asking me how my morning was going. Sensing the tension in the conversation I ask him what’s going on. Then he gets right to the point, and it’s SharePoint related. Having had my gooooood amount of SharePoint experience doing majority of the SharePoint site migrations to 2016, however this time the issue revolved around the old 2010 site and server that was setup and configured before my time there.

Long story short, I took the correlation ID and searched the good old UNLS logs (C:\Program Files\Common Files\Microsoft Shared\Web Server Extentsions\14\LOGS). Nothing really stood out, a couple access denied due to a secure store permission for a web part, which I knew about due to the account I was using to test, and saw this webpart error out before hitting the error page on a web part edit (a different webpart that was actually working fine and failing on edit). There are other blog posts on dealing with access denied on the secure store front so I’ll leave those out of this as they were not of value to me. Continuing through the log till the very last match on the correlation ID brought up a exception halt with the line reading “Invalid field name.” along with a bunch of inner system method calls down a usual stacktrace. The stack strace wasn’t really of much relevance so I did the best thing I could, google the UNLS issue about the invalid field name, and sure enough I stumble upon a technet blog post by a Brendan Griffen.

Now you can go ahead and read more on his issue and store there, and he seems to really be hooked about “FormURN” but my case didn’t really have anything to do with that, and he does cover more the details as to the fact that certain tables that are used for content types somehow missing certain fields (ahem columns), as we all know you don’t mess with the DB directly when dealing with SharePoint. Now I don’t even get into the nitty gritty of the commands he used to verify the missing fields (thinking about that now it could have made for a more interesting blog post….. oh well) since he covers the solution to recover the missing fields with two SharePoint powershell commands, and well running those two fields in my test environment (since I was quickly able to duplicate the issue in my test) it sure beat doing that then digging endlessly through DB’s for columns I’m not sure I’m even missing, and for logs this was the last line in it so it was this or nothing…

The solution

Command 1:

Disable-SPFeature –identity "Fields" -URL RootWebURL

You will be asked if you are sure, select yes.

Command 2:

Enable-SPFeature –identity "Fields" -URL RootWebURL

that was it, just like magic (didn’t require a reboot or even a iisreset) my dev was able to edit the web part, and I was on my way to help a user with their monitor.

I’m going to soon have some SharePoint posts about orphaned items stay tuned! As well as some awesome scripts to clean up old 3rd party plugins!

Posted on

STS Security Token Service on SharePoint 2013

Today I was bringing my stepping server back up. In this case I use it to upgrade content databases from 2010 -> 2016.

Since you can’t directly upgrade, since the config data had been wiped, I was going through the config wizard to get it rebuilt. Now the wizard will complain if the old website still exists. So for some reason I decided to remove all the old sites and app pools. figured it would get rebuilt.

Now the wizard completed without a hitch, and I was off creating a web app and some content databases to delete as I’d test and mount the 2010 content databases for staging.

Oddly after I had mounted the database I had noticed the server was failing to successfully call “Get-SPSite”, saying that it was due to the security token store service. There’s lots of links out there with similiar issues… such as this, this, this, this and even this …. most of which are dead ends.

There’s MS support page on this as well, however I may have accidentally deleted that App Pool…

Then I stumbled across this, a MS blog post, which I find a lil more useful usually cause they are more hands on… in this case since I was already hooped I gave the command a try, and it ran just like his…

I wasn’t sure if this was enough, then I found this and ran these commands as well…

$sts = Get-SPServiceApplication | ?{$_ -match "Security"}
$sts.Status
$sts.Provision()

after a reboot, all of a sudden Get-SPSite was working again!

Posted on

SharePoint User Full Control – Site has not been shared with you

I’ll keep this one short. After my recent SharePoint migration (ahem, 1 web app out of 6 I have yet to complete), I noticed my standard user account was not able to add pages to my new 2016 site. A little different then this Blog post about unable to edit, however the fix was exactly the same.

  1. First ensure you have site collection admin rights on the site collection in question.
  2. Load the site with this account (I noticed there’s only logout, and no longer sign in with another user under the user hamburger menu, so open a browser as the user with site collection admin rights).
  3. Go to Site Settings -> Master pages and page layouts
  4. In his case, as well as mine then library had unique permissions (not sure why I have yet to log into my old SharePoint page and see if it was like this from before the migration). Simple make it inherent permissions from the root site.

I was able to find this info from TechNet. I’m on there quite frequent, feel free to check out some of my posts. 😀 Maybe there’s a way I can add my TechNet profile to the word press social links. 😀 stay tuned.

Posted on

SharePoint 2010 Managed Service Accounts

The reason for this blog post was due to a domain migration which involved a SharePoint 2010 server. These were the symptoms, and all the steps I took to resolve them.

To start ensure you have set a new farm admin account.

E.G. stsadm -o updatefarmcredentials -userlogin domain\farmadmin -password PASSWORD
This is of course under the sharepoint bin directory and wont be part of the servers default path.
All Tasks moving forward will be done with this account (in my case the account has local admin rights as well as being the sharepoint farm admin permissions)

You might have come across an error such as this when working with SharePoint. Might have been from an admin removing a service account in AD, or in my case a whole domain change.

Image result for Error-Removing Managed Account

If you’re new to SharePoint you might simply panic before thinking and simply google and you might come across this.
Which sadly leads to a dead end. The reason his leads to a dead end while others have answers I’ll get to soon.
Next the simple thing you’d figure is to do as it says, reconfigure the service to run under a different account. To your dismay you discover the Central Admin page to make this change gives you this!

You might be thinking you’re in a catch 22 here. But fret not, when in doubt PowerShell. I love PowerShell and it only keeps getting better, in this case it’s our savour.
Remember when I stated that SharePoint link was a dead end. It was a dead cause there are different component types, 4 to be exact and I’m gonna tell you how to fix them all! With Sources!
First up the 4 different types!

1) Service Instance:

	Cmdlet:		Get-SPServiceInstance

	Use the comdlet to list all SharePoint Service instances, mark the ID. Place the service instance into a variable.

	E.G.		$WindowsTokenService=Get-SPServiceInstance -Identity ServiceGUID

	Once you have the variable, it should have a bunch of subclasses. In this case .service.ProcessIdentity. You can see it attributes by typing.

	E.G.		$WindowsTokenService.service.ProcessIdentity

	It should display the service account used to run the service. Simply change it via

	E.G		$WindowsTokenService.service.ProcessIdentity.Username="Domain\NewServiceAccount"

	*NOTE* This accuont needs to already be registered as a serivce account in SharePoint, either via the Central Admin page or Powershell.
	Then call the object'ssubclass update and deploy methods.

	E.G.		$WindowsTokenService.service.ProcessIdentity.Update()
	E.G.		$WindowsTokenService.service.ProcessIdentity.Deploy()

	That's it for basic SharePoint Service Instances.

2) Service Applications:
	
	Cmdlet:		Set-SPServiceApplicationPool

	The funny part about SharePoint Service instances is theres no Set type powershell comdlete for it. Thus the cmdlet used was a Get cmdlet.
	The funnt part about Service Applications is not to use the ServiceApplication cmdlet, but rather the ServiceApplicationPool cmdlets.

	E.G		Get-SPServiceApplicationPool -Identity SercurityTokenServiceApplicationPool | Set-ServiceApplicationPool -Account "Domain\NewServiceAccount"

	Don't forget to do an IIS reset. Then running the Get-SPServiceApplicationPool cmdlet the service application should have a set PrcoessAccountName.

3) Content Applications:

	Cmdlet:		[Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | ft Name

	Yeah you read that right, there's no direct PowerShell cmdlet for this one. You got to go deep... real deep. Anyway run the cmdlet to list all Content Applications.
	Once you have determined the one you need to change the service account for place it in a variable.

	E.G. 		$SPAppPool=[Microsoft.SharePoint.Administration.SPWebService]::ContentService.ApplicationPools | where {$_.Name -like "My Content App Pool Name"}

	Calling this variable will result in an output very similar to a Service Instance's Service.ProcessIdentity subclass. So you guessed it.

	E.G.		$SPAppPool.Username="Domain\NewServiceAccount"
	E.G.		$SPAppPool.Update()
	E.G.		$SPAppPool.Deploy()

4) Search Service:

	Cmdlet:		Get-SPEnterpriseSearchService

	Yup believe it another Get cmdlet to make a change, where are these Set counterparts you may ask, well that's a good fucking question. We should ask Microsoft.
	Anyway, if this hasn't annoyed you enough already chances are you haven't been a SharePoint admin for long, cause it's a rabbit hole. So to finish up here.

	E.G.		$SSS=(Get-SPEnterpriseSearchService).get_ProcessIdentity()
	E.G.		$SSS.Username="Domain\NewServiceAccount"
	E.G.		$SSS.Update()
	E.G.		$SSS.Deploy()

Sources:
General SharePoint 2010 Managed Service Accounts
Service Instances Source
Service Application Source
Content Application Source
Search Service Source

Once the Get-SPServiceAccounts shows all good on password expiry and no bad accounts exist, there should be no issues opening the Configure Managed Service Accounts section in Central Administration page of SharePoint 2010.
Happy Configuring. 🙂

To Paraphrase:

0) There is no way to paraphrase this.
1) Don’t break SharePoint.
2) Don’t break SharePoint.

Proudly powered by WordPress