The only thing that should be orphaned, is SharePoint itself…. ohhh ouch,<\/p>\n
<\/span>The Story<\/strong><\/span><\/h1>\njoking 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.<\/p>\n
<\/span>Slow SharePoint fixed… But…<\/span><\/h2>\nDuring 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.<\/p>\n
<\/span>The signs were clear<\/span><\/h2>\nLooking 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….<\/p>\n
![\"\"](\"https:\/\/i.imgur.com\/sdhhbrX.png\")
<\/a><\/p>\nWhooops how did I miss this… (ReportServer Feature…)<\/p>\n
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…<\/p>\n
<\/span> The search<\/span><\/h2>\nSource one<\/a>\u2026 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.<\/p>\nSource two<\/a> simple\u2026 lets try it…<\/p>\n<\/span>The Solution<\/span><\/h1>\nInstall 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.<\/p>\n
So Step 1: Grab Reporting Service<\/a> installers (my case SharePoint 2016)<\/p>\nStep 2: Install it;<\/p>\n
![\"\"](\"https:\/\/i.imgur.com\/KnbgdGS.png\")
<\/a>Next, Accept the EULA, Install<\/p>\n![\"\"](\"https:\/\/i.imgur.com\/t9ZPvSq.png\")
<\/a><\/p>\nSuccess.<\/p>\n
This makes the content type names behave correctly.<\/p>\n
![\"\"](\"https:\/\/i.imgur.com\/vSCJWjX.png\")
<\/a><\/p>\nStep 3: Enable it;<\/p>\n
Install-SPFeature -Path \"C:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\16\\TEMPLATE\\FEATURES\\ReportServer\"<\/em><\/pre>\n![\"\"](\"https:\/\/i.imgur.com\/9BRAM3L.png\")
<\/a><\/p>\nNow 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…<\/p>\n
Step 4: Disable the feature on all web applications<\/p>\n
Disable-SPFeature \u2013Identity ReportServer \u2013Url http:\/\/spsite.domain.com<\/pre>\n![\"\"](\"https:\/\/i.imgur.com\/gZmONR3.png\")
<\/a><\/p>\nStep 5: Uninstall the Feature:<\/p>\n
Uninstall-SPFeature -Identity e8389ec7-70fd-4179-a1c4-6fcb4342d7a0<\/pre>\n![\"\"](\"https:\/\/i.imgur.com\/ZpKXDLF.png\")
<\/a><\/p>\nStep 6: Uninstall the package:<\/p>\n
msiexec \/uninstall rsSharePoint.msi<\/pre>\n![\"\"](\"https:\/\/i.imgur.com\/CGEg0YJ.png\")
<\/a><\/p>\nI 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. \ud83d\ude00<\/p>\n
Now go enjoy a coffee. Thx, Jussi Palo!<\/p>\n
<\/span>The Second Solution<\/span><\/h2>\nOK, not gonna lie, I assumed it was all good, and that assumption came to bite me in the ass…. again, never assume.<\/p>\n
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”.<\/p>\n
Ughhhhh… what…<\/p>\n
So looking back at the Sites Content Types the Report Model Document content type still remained… ok what the….<\/p>\n
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!<\/p>\n
![\"\"](\"https:\/\/i.imgur.com\/apfB964.png\")
<\/a><\/p>\nCan never give me a break eh SharePoint…<\/p>\n
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…<\/p>\n
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…<\/p>\n
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…<\/p>\n
This requires you to have syadmin rights on the SQL Server instance hosting the SharePoint Content Databases. Open SSMS…<\/p>\n
SELECT *\r\nFROM WSS_CONTENTDB.[dbo].ContentTypes\r\nWHERE Definition LIKE '%Report%'<\/pre>\n![\"\"](\"https:\/\/i.imgur.com\/Vbj2ZgT.png\")
<\/a><\/p>\nFind 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<\/p>\n
USE WSS_CONTENTDB\r\nGo\r\nUPDATE dbo.ContentTypes\r\nSET IsFromFeature = 0\r\nWHERE ContentTypeID = *ID From above Query*<\/pre>\n
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.<\/p>\n
<\/span>The signs were clear<\/span><\/h2>\nLooking 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….<\/p>\n
<\/a><\/p>\nWhooops how did I miss this… (ReportServer Feature…)<\/p>\n
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…<\/p>\n
<\/span> The search<\/span><\/h2>\nSource one<\/a>\u2026 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.<\/p>\nSource two<\/a> simple\u2026 lets try it…<\/p>\n<\/span>The Solution<\/span><\/h1>\nInstall 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.<\/p>\n
So Step 1: Grab Reporting Service<\/a> installers (my case SharePoint 2016)<\/p>\nStep 2: Install it;<\/p>\n
<\/a>Next, Accept the EULA, Install<\/p>\n<\/a><\/p>\nSuccess.<\/p>\n
This makes the content type names behave correctly.<\/p>\n
<\/a><\/p>\nStep 3: Enable it;<\/p>\n
Install-SPFeature -Path \"C:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\16\\TEMPLATE\\FEATURES\\ReportServer\"<\/em><\/pre>\n<\/a><\/p>\nNow 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…<\/p>\n
Step 4: Disable the feature on all web applications<\/p>\n
Disable-SPFeature \u2013Identity ReportServer \u2013Url http:\/\/spsite.domain.com<\/pre>\n<\/a><\/p>\nStep 5: Uninstall the Feature:<\/p>\n
Uninstall-SPFeature -Identity e8389ec7-70fd-4179-a1c4-6fcb4342d7a0<\/pre>\n<\/a><\/p>\nStep 6: Uninstall the package:<\/p>\n
msiexec \/uninstall rsSharePoint.msi<\/pre>\n<\/a><\/p>\nI 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. \ud83d\ude00<\/p>\n
Now go enjoy a coffee. Thx, Jussi Palo!<\/p>\n
<\/span>The Second Solution<\/span><\/h2>\nOK, not gonna lie, I assumed it was all good, and that assumption came to bite me in the ass…. again, never assume.<\/p>\n
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”.<\/p>\n
Ughhhhh… what…<\/p>\n
So looking back at the Sites Content Types the Report Model Document content type still remained… ok what the….<\/p>\n
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!<\/p>\n
<\/a><\/p>\nCan never give me a break eh SharePoint…<\/p>\n
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…<\/p>\n
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…<\/p>\n
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…<\/p>\n
This requires you to have syadmin rights on the SQL Server instance hosting the SharePoint Content Databases. Open SSMS…<\/p>\n
SELECT *\r\nFROM WSS_CONTENTDB.[dbo].ContentTypes\r\nWHERE Definition LIKE '%Report%'<\/pre>\n<\/a><\/p>\nFind 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<\/p>\n
USE WSS_CONTENTDB\r\nGo\r\nUPDATE dbo.ContentTypes\r\nSET IsFromFeature = 0\r\nWHERE ContentTypeID = *ID From above Query*<\/pre>\n
<\/a><\/p>\nWhooops how did I miss this… (ReportServer Feature…)<\/p>\n
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…<\/p>\n
<\/span> The search<\/span><\/h2>\nSource one<\/a>\u2026 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.<\/p>\nSource two<\/a> simple\u2026 lets try it…<\/p>\n<\/span>The Solution<\/span><\/h1>\nInstall 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.<\/p>\n
So Step 1: Grab Reporting Service<\/a> installers (my case SharePoint 2016)<\/p>\nStep 2: Install it;<\/p>\n
<\/a>Next, Accept the EULA, Install<\/p>\n<\/a><\/p>\nSuccess.<\/p>\n
This makes the content type names behave correctly.<\/p>\n
<\/a><\/p>\nStep 3: Enable it;<\/p>\n
Install-SPFeature -Path \"C:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\16\\TEMPLATE\\FEATURES\\ReportServer\"<\/em><\/pre>\n<\/a><\/p>\nNow 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…<\/p>\n
Step 4: Disable the feature on all web applications<\/p>\n
Disable-SPFeature \u2013Identity ReportServer \u2013Url http:\/\/spsite.domain.com<\/pre>\n<\/a><\/p>\nStep 5: Uninstall the Feature:<\/p>\n
Uninstall-SPFeature -Identity e8389ec7-70fd-4179-a1c4-6fcb4342d7a0<\/pre>\n<\/a><\/p>\nStep 6: Uninstall the package:<\/p>\n
msiexec \/uninstall rsSharePoint.msi<\/pre>\n<\/a><\/p>\nI 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. \ud83d\ude00<\/p>\n
Now go enjoy a coffee. Thx, Jussi Palo!<\/p>\n
<\/span>The Second Solution<\/span><\/h2>\nOK, not gonna lie, I assumed it was all good, and that assumption came to bite me in the ass…. again, never assume.<\/p>\n
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”.<\/p>\n
Ughhhhh… what…<\/p>\n
So looking back at the Sites Content Types the Report Model Document content type still remained… ok what the….<\/p>\n
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!<\/p>\n
<\/a><\/p>\nCan never give me a break eh SharePoint…<\/p>\n
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…<\/p>\n
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…<\/p>\n
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…<\/p>\n
This requires you to have syadmin rights on the SQL Server instance hosting the SharePoint Content Databases. Open SSMS…<\/p>\n
SELECT *\r\nFROM WSS_CONTENTDB.[dbo].ContentTypes\r\nWHERE Definition LIKE '%Report%'<\/pre>\n<\/a><\/p>\nFind 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<\/p>\n
USE WSS_CONTENTDB\r\nGo\r\nUPDATE dbo.ContentTypes\r\nSET IsFromFeature = 0\r\nWHERE ContentTypeID = *ID From above Query*<\/pre>\n
Source two<\/a> simple\u2026 lets try it…<\/p>\n 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.<\/p>\n So Step 1: Grab Reporting Service<\/a> installers (my case SharePoint 2016)<\/p>\n Step 2: Install it;<\/p>\n Success.<\/p>\n This makes the content type names behave correctly.<\/p>\n Step 3: Enable it;<\/p>\n 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…<\/p>\n Step 4: Disable the feature on all web applications<\/p>\n Step 5: Uninstall the Feature:<\/p>\n Step 6: Uninstall the package:<\/p>\n 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. \ud83d\ude00<\/p>\n Now go enjoy a coffee. Thx, Jussi Palo!<\/p>\n OK, not gonna lie, I assumed it was all good, and that assumption came to bite me in the ass…. again, never assume.<\/p>\n 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”.<\/p>\n Ughhhhh… what…<\/p>\n So looking back at the Sites Content Types the Report Model Document content type still remained… ok what the….<\/p>\n 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!<\/p>\n Can never give me a break eh SharePoint…<\/p>\n 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…<\/p>\n 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…<\/p>\n 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…<\/p>\n This requires you to have syadmin rights on the SQL Server instance hosting the SharePoint Content Databases. Open SSMS…<\/p>\n 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<\/p>\n<\/span>The Solution<\/span><\/h1>\n
<\/a>Next, Accept the EULA, Install<\/p>\n<\/a><\/p>\n<\/a><\/p>\nInstall-SPFeature -Path \"C:\\Program Files\\Common Files\\microsoft shared\\Web Server Extensions\\16\\TEMPLATE\\FEATURES\\ReportServer\"<\/em><\/pre>\n
<\/a><\/p>\nDisable-SPFeature \u2013Identity ReportServer \u2013Url http:\/\/spsite.domain.com<\/pre>\n
<\/a><\/p>\nUninstall-SPFeature -Identity e8389ec7-70fd-4179-a1c4-6fcb4342d7a0<\/pre>\n
<\/a><\/p>\nmsiexec \/uninstall rsSharePoint.msi<\/pre>\n
<\/a><\/p>\n<\/span>The Second Solution<\/span><\/h2>\n
<\/a><\/p>\nSELECT *\r\nFROM WSS_CONTENTDB.[dbo].ContentTypes\r\nWHERE Definition LIKE '%Report%'<\/pre>\n
<\/a><\/p>\nUSE WSS_CONTENTDB\r\nGo\r\nUPDATE dbo.ContentTypes\r\nSET IsFromFeature = 0\r\nWHERE ContentTypeID = *ID From above Query*<\/pre>\n