This post is about the default language of a new site in SharePoint Online. There are some pros and cons of using English as the default language for Non-English sites.
In my case I want to know what is better for Swedish users:
A site with English as default and Swedish as an alternate language (among many other alternate languages)?
A site with Swedish as default?
Today, when you create a site, English is pre-selected in the form, you have to choose Swedish actively. When you create a team, the underlying SharePoint Site will have English as the default language.
English is pre-selected when you create a new site
There are a couple of advantages of starting from English:
Stream-lined urls for Document Libraries and Lists. For an admin or a support guy, it is better to know that the Url for the first document library is ../Shared Documents/ and not Delade dokument. It is easier to find things and provide help if needed.
It is less error-prone to create and update Calculated fields from templates.
The disadvantages are:
The choice fields are in English. While the most of the UI is available in all alternate languages by default, the values in choice fields can only be in one language, and it will be in English, e.g. Task status.
More a big caveat: Sort order, a tiny but an important setting for how things should be sorted. More on that below.
Choice Field Values are in English even for a Swedish user
Sort order caveat
If you keep the General Sort Order, the Swedish ÅÄÖ will be treated as AAO, which means Ö-words that are expected to be in the end of a list, will show up in the middle. An important setting for business. And the bad part is you need to change it to Finnish/Swedish Sort Order before you add an indexed column (or a built-in list (e.g. Tasks) that adds indexed columns) .
For a Swedish site (a site where the majority of users are Swedish who expect the right sort order, the very first thing you have to do is to change the sort order (and also the time zone, and 24h clock, and Monday as the first day of week etc). Once you get an indexed column, no matter if you have zero list items, you will get an error like this:
These are my favourite tips and tricks. These are only those who me and my colleguages have tried out.
Architecture tips
Keep it slim
Functions should do one thing and they should do it well. When you develop it in C# and Visual Studio, it is so tempting to develop a “microservice” in a good way, you add interfaces, implement good patterns, and all of a sudden you get a monolith packaged in a microservice. If your function grows, stop, rethink. Better to see how it input and output bindings can be used. Also orchestration with Logic Apps or Durable Functions can help.
Automated Deployment
It might be an obvious one, but it is super easy to setup CI/CD for Azure Functions in Azure DevOps. Set it up as early as possible. Don’t rely on publishing from Visual Studio.
Environments
Different environments like Production and Staging (Test, UAT, QAT, verification), and DEV are not straight forward anymore, when everything is reactive and micro. But it is good to have at least two setups: one for Production and one for Staging. Especially separating the storage accounts has been proven to be a success story. You can have the same queue name, but different connections. Deploying to Staging and Production will be easier. The functions in different “environments” will write/read a queue with the same name but in different storage accounts.
I also find it convenient to have postfix in the azure function names, like collect-shipments-staging and collect-shipments-production.
If it is possible, use separate resource groups for the “environments”.
Instead of adding queue messages in code, define it as an output. You can even add multiple messages. This saves you instantiating of CloudStorageAccount which is a good thing for performance.
Take Last Run into account
Just check the timer parameter: timer.Schedule.Last for the time when your Azure Function ran last.
Reuse HttpClient
This tip is from CloudBurst in Malmö in September 2019. Eventhough your function runs on a consumption plan, the chance is big that your code will run on the same server, which means that you can reuse some resources, like HttpClient.
The issue I got was that indexed columns were there. You can try to remove indexed columns and re-add them. But it is not the best solution. In my scenario, it was an indexed column that I couldn’t remove.
The reason why I use a combination of PnP and CSOM (Load, Update, ExecuteQuery), is that I have not found a way of updating RegionalSettings in PnP.
Site Collection App Catalogs (SCAC) are much appreciated, thank you, Office 365 Team. Here is a couple of tips and tricks for SCAC.
Tip #1 You don’t need Tenant Admin rights to add a new Site Collection App Catalog
I have seen many blogs, forum threads etc that state that only Global Tenant Administrators can add new Site Collection App Catalogs. The truth is that a SharePoint Admin rights are enough. The trick is to make that SharePoint Admin Account to a site collection administrator of the app catalog site. To be precise the account that adds a new SCAC must have Manage Web Permissions, as stated in error message:
Add-SPOSiteCollectionAppCatalog : Must have Manage Web Site permissions or be a tenant admin in order to add or remove sites from the site collection app catalog allow list
Tip #2 List all Site Collection App Catalogs
To list all the SCACs in your tenant navigate to that url:
Currently, it’s not possible to list all site collections in the tenant that have the site collection app catalog enabled.
The fun fact was that I sherlocked it since I knew my account needed access to the main App Catalog site. So there must be some information that is stored. How is it done a là SharePoint – yes, it is stored in a hidden list. Like in the olden days. 🧐
This is about a topic brought up by Waldek Mastykarz: Just because you can should you use the Office 365 CDN. In my post I want to take a closer look at the private CDN option in Office 365. Please note, the whole thing is subject to change, and it reflects the circumstances at the time of writing – 2019-08-26.
I’ll skip the introduction of Office 365, let’s jump directly to the Private CDN option. Consider following scenarios.
I am developing SPFx solutions, is the Private Office 365 CDN something for me?
I use Modern Team Sites and Communication Sites. Is the Private Office 365 CDN something for me?
No, the urls are changing. You cannot “hardcode” them. Automatic URL Rewrite works only on classic Publishing Sites.
I have Provider Hosted Add-Ins. Is the Private Office 365 CDN something for me?
No, the referrer needs to be a subdomain of sharepoint.com.
Security
The whole point of having a private CDN is that it is not available for strangers. But when you enable it, you’ll see an eligible warning:
WARNING: This is a feature built on a 3rd party application with privacy and compliance standards that differ from the commitments outlined by the Microsoft Office365 Trust Center. Any data cached through this service does not conform to the Microsoft Data Processing Terms (DPT) and is outside of the Microsoft Office365 Trust Center compliance boundaries.
Adding Referer: <subdomain>.sharepoint.com as a Request Header is needed to download a resource.
If you remove an asset from the private cdn origins, it takes up to 15 minutes for the link to be invalidated. Opposed to an immediate effect for a direct link to an asset in a document library.
To keep it more secure, the default private cdn origins should not be included, especially */SITEASSETS, Because site assets can have important information, and this makes every single site assets library vulnerable, asterisk means all.
Even the CDN Policies should be restrictive.
Overall, if the usage area is small, the performance gain is little, we should not enable it at all. Because: any cached data in a private Office 365 CDN is outside of the Microsoft Office365 Trust Center compliance boundaries.
Performance
I have tried the private CDN. My setup was a document library with three versions of a picture that was 2,4MB that I put to three different libraries:
privatecdnorigin/africa_private.jpg
publiccdnorigin/africa_public.jpg
nocdnorigin/africa_nocdn.jpg
On the publishing site I inserted three images on a page and compared the load time in the DevTools. During this test I had Cache Disabled. I got following results:
private, public, nocdn
3.04s, 3.03s, 3.24s
1.78s, 1.77s, 1.75s
1.99s, 1,95s, 3.32s
1.67s, 0.73s, 0.72s
1.73s, 1.71s, 1.97s
1.60s, 1.58s, 1.67s
So only once I got a bigger difference, otherwise it took the same time to load a picture from a document library without CDN.
To be fair, it is a very simple performance test. Tests with bigger files, different geographical locations would probably give a more detailed view of that. And still, without a URL Rewrite that is only present on Publishing sites, you cannot take use private cdn origins.
Conclusion
Private CDN in Office 365 can be interesting in future, but today, the usage is narrow (only publishing sites can refer to assets in a private CDN), the performance gain is little and lower security makes it to a bad choice.
Svenskt gränssnitt i Office 365 är inte självklart. Här är en lista på översättningar som jag stött på som går att härleda, men som inte är helt etablerade i svenskan.
There are many resources on the internet that list _layouts/15 urls in SharePoint. Some are outdated, some are too short, some are to long. Here is my list of the urls, that I am going to update when I need. All the urls start with [Your-Tenant].sharepoint.com/sites/[Your-Site]/_layouts/15/
Here we go:
viewlsts.aspx – Site Contents, Modern View
viewlsts.aspx?view=14 – Site Contents, Classic View
appinv.aspx – Grant Permissions to an App
appregnew.aspx – Register a new SharePoint Application
appprincipals.aspx – List Registered Add-Ins
CreateGroup.aspx – Create Site page (Team and Communication)
TA_AllAppPrincipals.aspx – List all app principals
Recent Comments