Allow Custrom Scripting on a specific SP site

[Chad_V_Kealey]

Some of our departments have made use of custom templates in SP doc libraries in our old 2010 environment and want to do the same in their Group-connected site in Office 365. However, trying to upload a template for a document content type throws an "Access Denied" message/dialog, even for a user who is a site collection admin.

In researching this, it appears that sites need to be set to allow "custom scripting" for this feature to work, although I'm not sure why (a .dotx file isn't a script, so far as I know). At any rate, this command, run in Powershell, should set the appropriate property on the site:

Set-SPOsite https://your-domain.sharepoint.com/sites/modern-site -DenyAddAndCustomizePages 0

However, when I try it on any sites in our tenant (standalone Site Collections or Group-connected sites), I get this error:

Set-SPOSite : The managed path sites/<siteURL> is not a managed path in this tenant.
At line:1 char:1
+ Set-SPOSite https://drexel0.sharepoint.com/sites/BusinessServicesSupp ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Set-SPOSite], ServerException
+ FullyQualifiedErrorId : Microsoft.SharePoint.Client.ServerException,Microsoft.Online.SharePoint.PowerShell.SetSite

I'm signed in as a SharePoint Admin, and even made sure the admin account is a site collection admin in the sites (which I don't think should matter, just covering the bases), so I'm not sure why this isn't working.

[#2]

try Set-SPOSite -identity "site here in quotes" -DenyAddAndCustomizePages $false

[#3]

@Deleted, no dice. Same message. Based on what it says, it seems like the change can only be made to site which are "managed paths" in the tenant, but I'm not sure exactly what that means or how to make a site a managed path. To me, it seems logical that sites created by a SharePoint admin (via the admin center or Powershell) would, by default be considered "managed", while Group-connected sites (created by end/non-admin users) may not.

[#4]

Group connected and classic sites should all work the same that's odd your getting that message.

[#5]

I'm trying this using an account with the SharePoint Admin role (not Global Admin). I wonder if that has something to do with it? It shouldn't (IMO), because it's strictly a SharePoint thing I'm modifying; it shouldn't have any bearing on anything else in O365. 

[#6]

Ahhh, yeah that's probably going to be it then. They still haven't quiet got that ironed out yet with the roles. Does it let you explicitly assign your user account as site admin using
set-spouser -loginname user@user.com -site "siteurl" -issitecollectionadmin $true
I know if your just a group owner and not explicitly assigned that can cause issues too. If you get same error trying to do that for yourself then it most likely is the global admin issue.

[#7]

---

@Deleted wrote:
Ahhh, yeah that's probably going to be it then. They still haven't quiet got that ironed out yet with the roles. Does it let you explicitly assign your user account as site admin using
set-spouser -loginname user@user.com -site "siteurl" -issitecollectionadmin $true
I know if your just a group owner and not explicitly assigned that can cause issues too. If you get same error trying to do that for yourself then it most likely is the global admin issue.

---

I was able to set my SP Admin user as site collection admin using the cmdlet, but still no luck with allowing custom script. I'll have one of our Global Admins try it and see if it works for them.

[#8]

I tried this in another (test/dev) tenant we have and it works fine. I believe I have the same permissions in both environments, and the only difference in configuration is that in production, we have the Create Site button hidden, while in dev/test, it's not. I don't think that should have anything to do with this setting, but it might. 

[#9]

OK, after some additional testing today, I figured out the issue. When specifying the site URL, I was including the trailing slash (e.g.: https://<tenant>.sharepoint.com/sites/<siteURL>/), so Powershell was expecting that (sites/<siteURL>/) to be a managed path, when it is not. Leaving the slash off (e.g.: https://<tenant>.sharepoint.com/sites/<siteURL>), it works fine.  

[#10]

Wow.... thanks for following up, it crossed my mind to suggest that, but figured you had put it in chat wrong... lol. Doh! Glad you figured it out.