How to fix error could not load type 'Microsoft.SharePoint.Administration.DesignPackageType' error when import Microsoft.Online.SharePoint.PowerShell module

When you try to import Microsoft.Online.SharePoint.PowerShell module:

Import-Module -Name Microsoft.Online.SharePoint.PowerShell

you may get the following error:

Import-Module : Could not load type 'Microsoft.SharePoint.Administration.DesignPackageType' from assembly 'Microsoft.SharePoint.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.

also error can be the following:

Import-Module : Could not load type 'Microsoft.SharePoint.Client.Publishing.PortalLaunch' from assembly 'Microsoft.SharePoint.Client.Publishing, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c'.

The main problem is that PowerShell tries to use on-prem CSOM assemblies (which have version 16.0.0.0) instead of online (with version 16.1.x.x). There are some articles and posts which recommend to manually remove Microsoft.SharePoint.Client folders from GAC. It should not be done! Especially if you have on-prem Sharepoint installation on the same server – this installation may be broken because of that.

The reason of this error is conflicts between different versions of Sharepoint Online SDKs (SharePoint Client Components, SharePoint Online Management Shell). So correct way to solve this problem is the following:

1. Go to Control Panel > Programs and features and uninstall all instances of SharePoint Online Management Shell and SharePoint Client Components

2. Open PowerShell console and uninstall existing versions of Microsoft.Online.SharePoint.PowerShell module:

Uninstall-Module -Name Microsoft.Online.SharePoint.PowerShell -AllVersions

3. After that close PowerShell, open new session and install latest version of Microsoft.Online.SharePoint.PowerShell module:

Import-Module -Name Microsoft.Online.SharePoint.PowerShell

This time it should go without error.

How to enable iOS universal links in web-facing Sharepoint on-prem site

Universal links allow to open mobile app when user clicks it inside the site. I.e. if user has appropriate mobile app it will be opened instead of regular browser page which will give better user experience on mobile devices. In this post I will show how to configure universal links for iOS in web-facing Sharepoint on-premise site. At the same time I won’t write about all steps like building mobile app itself, getting its app id, etc – please refer to appropriate resources related with mobile apps development for that.

In order to enable universal links for iOS on your web-facing Sharepoint on-prem site the following steps have to be done:

1. create AASA (Apple app site association) file. File name should be exactly “apple-app-site-association” without extension. It should contain data in json format with predefined structure (see below)
2. put it to the root folder of web-facing site
3. ensure that AASA file is available for anonymous users (robots) with Content-Type = “application/json”

This is how AASA file may look like:

{
  "applinks": {
    "apps": [],
    "details": [ { "appID": "{appId}", "paths": ["*"] } ]
  }
}

(use you app id instead of {appId} placeholder). When file is ready we need to copy it to the IIS folder of our Sharepoint site. Next step is to provide anonymous access and set correct content type. It can be done by modifying web.config of Sharepoint site – we need to add new location element here under configuration tag (usually in web.config of Sharepoint site there are many others location elements – so just put them together):

 <location path="apple-app-site-association">
    <system.web>
      <authorization>
        <allow users="*" />
      </authorization>
    </system.web>
    <system.webServer>
      <staticContent>
        <mimeMap fileExtension="." mimeType="application/json" />
      </staticContent>
    </system.webServer>
  </location>

It will make AASA file available for anonymous users and will set content type to “application/json”.

The last step is to verify that everything is configured properly. It can be done on AASA validator. Result should look like this:

At the end you should have universal links enabled for your web-facing Sharepoint on-prem site.

Update 2020-10-01: guide for enabling Android App links on Sharepoint site is available here: How to enable Android App links in web-facing Sharepoint on-prem site.

Call AAD secured Azure functions from Postman

It is often needed to test our AAD secured Azure functions from client applications like Postman. In one of my previous articles I showed how to call secured Azure functions from C# and PowerShell (see Call Azure AD secured Azure functions from C#). Let’s see now to to call them from Postman app – in this case we won’t need to write any code for testing our functions.

First of all we need to obtain access token. If app permissions are used we may use the same approach as in article mentioned above. For delegated user permissions you may go to SPFx page which calls Azure function, open browser Network tab, find call to some Azure function there and copy access token from Authorization header (value after “Bearer” part).

After that go to Postman and create new request using url of Azure function (it can be copied from Azure portal > Functions app) and correct http verb. On Autorization tab set Type = “Bearer Token” and copy access token to the Token field:

After that on Headers tab set correct content type if needed (e.g. application/json):

Then press Send. After that we should get results from AAD secured Azure function in Postman.

How to identify whether SPFx web part is running in web browser or in Teams client

As you probably know it is possible to add Sharepoint Online page as a tab to Team’s channel so it will be shown inside Teams: both when you access it from web browser via https://teams.microsoft.com or from native client (desktop or mobile). It may be needed to identify from where exactly Teams are accessed in order to provide better user experience for this particular client (e.g. add extra css, use different caching mechanisms, etc). In order to do that we may inspect User-Agent header (navigator.userAgent in Typescript) for different clients. In the following table I summarized values of User-Agent header for mentioned scenarios:

Accessed from	User agent
Desktop browser (Chrome)	Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
Mobile browser (Chrome on Android)	Mozilla/5.0 (Linux; Android 10; …) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.81 Mobile Safari/537.36
Teams web client in desktop browser (Chrome)	Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 SPTeamsWeb
Teams web client in mobile browser (Safari on iPad). Chrome mobile browser on Android and Safari on iPhone are not supported browsers for Teams web client	Mozilla/5.0 (Macintosh; Intel Mac OS X …) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Safari/605.1.15 SPTeamsWeb
Teams native desktop client	Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Teams/1.3.00.21759 Chrome/69.0.3497.128 Electron/4.2.12 Safari/537.36
Teams native mobile client (Android)	Mozilla/5.0 (Linux; Android 10; …) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/85.0.4183.81 Mobile Safari/537.36 TeamsMobile-Android
Teams native mobile client (iPhone)	Mozilla/5.0 (iPhone; CPU iPhone OS … like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 TeamsMobile-iOS
Teams native mobile client (iPad)	Mozilla/5.0 (iPad; CPU OS … like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 TeamsMobile-iOS

Those parts which allow to identify current client type are highlighted by bold font. I.e. if we have TeamsMobile-Android or TeamsMobile-iOS in User-Agent it means that SPFx is running in Teams native mobile client. If we have SPTeamsWeb – web part is running in web client.

Redirect traffic from single site collection in Sharepoint on-prem via URL rewrite IIS module

Suppose that you have Sharepoint on-prem web application with multiple site collections which have own urls and need to perform maintenance work on one of these site collections so others will remain working. In order to do that you may temporary redirect traffic from this site collection to external page (e.g. to maintenance page hosted outside of this site collection). Technically it can be done by adding URL rewrite rule to Sharepoint web app in IIS. Rule will look like this:

This rule will redirect traffic from site collection with url /test to external site http://example.com. This is the same rule in xml which is added to web.config of Sharepoint web app:

<rewrite>
  <rules>
	<rule name="MyRule" enabled="true" stopProcessing="true">
	  <match url="test/*" />
	  <action type="Redirect" url="http://example.com" appendQueryString="false" redirectType="Found" />
	</rule>
  </rules>
</rewrite>

Note that if you perform temporary maintenance work on site collection then Redirect type should be set to Found (302) like shown above and not to Permanent (301). In case of permanent redirect browser will cache response and will redirect users from this site collection even after maintenance will be completed and rule will be removed from the site.