Error enabling Office 365 CDN - Method "GetTenantCdnAllowedFileTypes" does not exist

Brass Contributor

I was trying to enable the private and public CDNs for our tenant but I was getting error with the Set-SPOTenantCdnEnabled PowerShell command - regardless of the CdnType switch - public or private.

 

I am running the latest SharePoint Online Management Shell and I am a tenant admin.

9 Replies

Hi @Kiril Iliev,

Only logical reason for this would be that you have SharePoint Online Clinet Components SDK (https://www.microsoft.com/en-us/download/details.aspx?id=42038) installed on your machine where you are using these PowerShell cmdlets. This error is then actually raised by the assembly conflict in your local machine and it's not coming from SharePoint Online. 

 

Challenge with the SDK is that it installs CSOM assemblies to GAC, which then overrides them to be used by the PowerShell cmdlets when they are used in PowerShell session. In general we do NOT recommend using this SDK, rather reference the needed assemblies as a NuGet package (https://www.nuget.org/packages/Microsoft.SharePointOnline.CSOM), so that you'll get the latest and greatest APIs for your solutions.

 

If you uninstall the SDK from your machine, PowerShell cmdlets will use locally deployed assemblies, whcih should resolve your issue. If this is not the scenario or you'll still have the issue regardless of uninstalling this SDK, there's something else wrong. 

 

Hopefully that solves it.

I have done the following:

 

- uninstalled the SDK

- restarted the SharePoint Online Management Shell

- Added reference to the DLLs with version 16.1.6323.1200 (latest as of now) via Add-Type -Path "PathToDll" for Microsoft.SharePoint.Client.dll, Microsoft.SharePoint.Client.Runtime.dll and Microsoft.Online.SharePoint.Client.Tenant.dll (I believe that the needed methods would be all in the last assembly, but added the rest of the CSOM assemblies just to be sure)

- Tried to run the script entirely in the Windows PowerShell ISE as"

 

$securePassword = ConvertTo-SecureString $Password -AsPlainText -Force 
$cred = New-Object System.Management.Automation.PSCredential -ArgumentList $username, $securePassword

Connect-SPOService -Credential $cred -Url $tenantAdminUrl

Add-Type -Path "PathToDlls\Microsoft.SharePoint.Client.dll" 
Add-Type -Path "PathToDlls\Microsoft.SharePoint.Client.Runtime.dll" 
Add-Type -Path "PathToDlls\Microsoft.Online.SharePoint.Client.Tenant.dll" 

Set-SPOTenantCdnEnabled -CdnType Public -Enable $true

 

Still getting Set-SPOTenantCdnEnabled : Method "GetTenantCdnAllowedFileTypes" does not exist.

 

Thanks,

Kiril

You don't need to reference any DLLs when you are using SPO Management Shell cmdlets, so that part is definitely not needed, but it does not explain the exception what you are seeing, since that would still indicate that a wrong CSOM assembly is loaded from GAC to the execution.

 

Following part is not needed, since SPO cmdlet's do load the CSOM assemblies automatically. That would be only needed if you would use native CSOM in your scripts.

 

Add-Type -Path "PathToDlls\Microsoft.SharePoint.Client.dll" 
Add-Type -Path "PathToDlls\Microsoft.SharePoint.Client.Runtime.dll" 
Add-Type -Path "PathToDlls\Microsoft.Online.SharePoint.Client.Tenant.dll" 

 

I took another approach and something wierd happened - a console application with the latest PnP Core component NuGet package. Here is a sample code:

 

 Tenant tenant = new Tenant(adminCtx);
 tenant.SetTenantCdnEnabled(SPOTenantCdnType.Public, true);
 adminCtx.ExecuteQueryRetry();
 var isEnabled = tenant.GetTenantCdnEnabled(SPOTenantCdnType.Public);
adminCtx.ExecuteQueryRetry();
// debug mode -> check isEnabled.Value property

At first, it has enabled the public Cdn, but later when I tried to add a public CDN origin to one of my libraries (with the AddPublicCdnOrigin), it threw an exception that the Public CDN was disabled. Running the above code, gave me that the CDN's value was set to false for some reason, regardless if I set it again through the C# code to true.

Microsoft just get the situation worse !

Can't find a definitely working instruction!

The law needs to split the Microsoft in two!

Hi George,

didn't quite get the message completely, but if you are looking for documentation, here's the official documentation in the docs.microsoft.com. Feel free to start up a new discussion in MS Tech Community and cc me in the discussion if you still have other questions or challenges.

 

All feedback on the documentation and guidance is more than welcome. Thanks for your input advance. 

 

 

The point is that this is not a working document!

The document link that you send doesn't work. That is why people has the forum to discuss how to working around!

The Microsoft needs to have a clear document mention all the dependency of the Dlls, versions.

Currently, developers are facing Microsoft "dll hell" or "package hell". The latest package doesn't even remove the old package. The different packages over write the assemble each other.

So: In able to run this piece of code what really needs in terms of Dlls/packages/CSOM to get ride of this annoyed error "

Get-SPOTenantCdnEnabled : The term 'Get-SPOTenantCdnEnabled' is not recognized as the name of a cmdlet, function, "

?

 

The tool suppose to help the developers to make the life easy. Now we have to figure out which version will work and how to make the tool works!

 

 

Hi,

I'm not sure what packages we are talking in here exactly, but it's true that the PowerShell msi for SharePoint Management Shell would need to be always uninstalled and then installed. Not really a massive job to do. 

 

If you install SPO Management Shell from the following location, you should not have any issues with any dll's or packages. If you do have issue, would like to have more details to understand what is exactly wrong and what exactly do you mean with "dll hell" or "package hell" in this context, so that we can fix it. Unfortunately, that term as such does not provide sufficient amount of details to fix this for the future. Also unclear on what exactly you are referring to a term "tool".

 

This is evolving with new versions as we add new capabilities to SharePoint Online. 

 

This post is quite old so assumption with the latest documentation and guidance has been that it's suitable for reuse since we have NOT received this kind of input recently. Thanks for the additional details advance. 

Thanks Vesa.

This one seems a correct one, but I got error" The specified account already exists" during the installation. I have to go to the system registry (regedit) to search string "SharePoint Online Management Shell" and delete all related entries.

Finally it worked.

Hope others can find this place to make it work.

George