These are my findings around Modern Sites without Office 365 Groups. It is, of course, a subject to change.
Today (2020-02-21) when you create a Modern Team Site without a group, you will get a site with the template STS#3. This oldie has been around for a while, hasn’t it?
I would always recommend creating Office 365 Group Connected sites.
How it is created
Through PowerShell/REST or from SharePoint Home, if your account is not allowed to create Office 365 Groups, it will automatically create a site without a group.
Site Creation Speed
It is really fast, much faster than the old STS#3, so something is different.
Custom Script
CustomScript is enabled. Which is the same as DenyAddAndCustomizePages=Disabled. CustomScript is a security risk, so I hope Microsoft will change that.
Groupifying
Yes, connecting to a new group is possible.
Listing Team Sites without Office 365 Groups
In SharePoint Admin you can filter them based on “Team Site (no Office 365 group)”
Want to translate your MS Forms into other languages? Create a form, not a quiz. It is available in both Forms and Forms Pro licenses.
Today I want to share one of my findings. One of those that seem obvious once you know, but that take time to find out.
Unfortunately, there is no official comparison of what is included in MS Forms vs. MS Forms Pro. So I thought that the ability to have forms in multiple languages was connected to the license.
It showed after many tests, that it is up to the type of form. The Form has the “Multilingual” feature. The Quiz does not have. Why? I don’t know. đ
Lesson learned: If you want to have your form in different languages, create a form, not a quiz in MS Forms.
One of the reasons why it is confusing is also the translation into Swedish.
Form – FormulĂ€r
Quiz – FrĂ„geformulĂ€r. You can say “Quiz” in Swedish, too. FrĂ„geformulĂ€r is very confusing.
English interface of MS FormsMulilingual only availalbe in a form, not a quiz
Sometimes all you need is just a simple static web page: instructions, a landing page, a collection of links. I think I have a perfect use case for Sway. Consider a scenario similar to what Laura Kokkarinen writes in her blog post:
An external user invitation needs an inviteRedirectUrl. Usually it is myapps.microsoft.com. In Laura’s case it was a given extranet url.
In our case we don’t know where an external user will land. After the invitation the external user will be added to some team or a collaboration site.
The default myapps.microsoft.com is a tool where a user can administer his account and accesses, but it might be a confusing place to be sent to after the invitation acceptance process.
A simple static page with clear information is just enough in our case. Fortunately, there is Sway, a simple (but still great) web page builder.
An example of a landing page, defined in Sway.
Following alternatives were considered for our landing page:
An “extranet” page in SharePoint Online. It takes time to set up if you don’t have an extranet.
A page in a public portal. Comms and IT must be involved.
A static web page in a blob storage / Azure CDN. It requires some basic web development for design and IT-driven deployment.
Azure App or Azure Function. Actually here it would mean going beyond static. For the initial phase, serving a static page, would also mean basic development and deployment by IT.
Advantages of a Sway page
Easy to create a static web page
Beautiful templates and an easy way to alter the design
Can be driven by the business/comms completely. We only need the url (to put into the invitation call to MS Graph).
Does not require any development or deployment.
Videos, documents can be embedded easily
A sway can be shared with anyone using the link. It means no additional infrastructure steps for this to work (such as firewall, dns etc).
There are some disadvantages, too:
The domain is too generic: sway.office.com. It might look suspicious to some users. Maybe there is a way to use own domain?
A Sway cannot have different languages and switch them based on the user’s locale. It would be great to have something similar to the “Multilingual” functionality in Forms. But still, as a static web page, Sway is doing great, even without the “Multilinguality”.
Summary
Sway is an easy “business friendly”, no-code solution for simple, still good-looking web pages, that can be created and updated in no time and shared easily. Being a member of the bigger Microsoft 365 ecosystem, it fills a certain gap where the business can work together with IT and deliver solutions faster.
Jag förstÄr att det Àr vÀldigt mycket kod för att fÄ till kalendervyn och att det inte Àr sÄ lÀtt omvandla till ett modernt utseende, men det stÀller till eftersom det upplevs som gammalt och inte anvÀndarvÀnligt ute i verksamheten.
Varför behövs en SharePoint-kalender
Jag ska lista nĂ„gra alternativ och förklara varför en gammal dinosaurie Ă€r fortfarande det enda vettiga alternativet (i vĂ€ntan pĂ„ en “modernisering” av lsitan)
En Office-365-gruppkalender
Det Àr en bra funktionalitet för en enkel kalender. Den saknar:
Stöd för extra kolumner och innehÄllstyper
Den Àr svÄr att dela med externa anvÀndare
HĂ€ndelser (Events)
Om du inte hittar lÀnken till den hÀr sidan, finns den under <site>/_layouts/15/Events.aspx. En snygg modern sida som kan visa kalenderhÀndelser frÄn flera kalendrar pÄ SharePoint-siten. Dess begrÀnsningar Àr:
GÄr inte att anpassa, eftersom det Àr en systemsida (layous-sida)
Den visar bara det minimala om hÀndelser
En kalender utanför Office 365
Har man egen kalenderdata, Àr man friare, men man förlorar fördelarna med att ha/betala för en dyr platform. Om man ocksÄ har ett eget grÀnssnitt för det kostar det att i lÀngden med alla anpassningar och buggrÀttningar.
SPFx-lösning
I SharePoint skulle man kunna ha en SPFx-lösning för att presentera kalenderdata pÄ ett snyggt sÀtt. Men det fÄr avvÀgas mot kostnader. Det fina med inbyggda kalendern var att den bara fanns dÀr, den ingick i plattformen.
Kalendern i SharePoint
Till fördelarna av kalendern i SharePoint hör:
Det Àr en del av ett större ekosystem. Power Automate eller PowerApps kan kopplas pÄ, som ett exempel. Det visas ocksÄ i moderna Events.aspx
Det Àr anpassningsbart pÄ ett enhetligt sÀtt, som alla andra listor. AnvÀndare med rÀtt behörighet kan skapa nya kolumner, definiera innehÄllstyper med mera.
PnP-mallramverket kan bÄde exportera och importera en kalender.
Listvyer, behörigheter, mappar, allt det ingÄr om man behöver det, pÄ samma sÀtt som det gör för alla andra listor i SharePoint.
Möjlighet till sök och aggregering ifrÄn flera siter.
En chans att det moderniseras utan att man behöver investera nÄgot i det extra.
En förenklad vy genom “HĂ€ndelser” av samma kalenderlista.
Lite tips och tricks för gamla kalendern
HÀr kommer en liten samling av enkla men intressanta tips för gamla kalendern.
#1 VÀlj tid för en ny hÀndelse med en annan innehÄllstyp pÄ ett smidigt sÀtt
Det hÀr har varit en av de sakerna som man varit mest frustrerad över. NÀr en kalender har flera innehÄllstyper, gÄr det inte att byta innehÄllstyp i NewForm nÀr du klickar i kalendervyn.
Om du vÀljer en annan innehÄllstyp, mÄste du manuellt ange tiden. Det tar tid. Föreslagna tiden Àr bara aktuella timmen hÀr och nu.
Tipset Àr att:
Hitta rÀtt dag och markera rÀtt tid i kalendervyn. Rutan fÄr en blÄaktig fÀrg.
Klicka pĂ„ “Ny hĂ€ndelse” i Ribbon (vad var svenska namnet för det?).
Vips sÄ har du tid och datum rÀtt ifrÄn början
#2 Kalenderöverlag
En klassiker, en av mina favoriter Ă€r möjligheten att visa kalenderhĂ€ndelser med olika fĂ€rger – kalenderöverlag. TyvĂ€rr Ă€r det begrĂ€nsat med fĂ€rger.
#3 Visa veckovyn utan att Àndra instÀllningar
I lĂ€nken till din kalender (t.ex. i vĂ€nstermenyn), lĂ€gg till “?calendarperiod=week” i URL:en, sĂ„ visas veckovyn automatiskt.
If you want to remove the Microsoft Teams Banner on your SharePoint Site, the only thing you need is to set a web property on a site: TeamifyHidden=TRUE. I’ll give you some guidance below. But before you do that, consider following:
If there is already a team created for a group connected site, the prompt won’t show up. Why fix something that is not a problem?
Only group owners will get the prompt, if they are few and they know what it is, it is better to let them to decide whether to create or not to create a team.
Only licensed users within your organization will be shown that choice. No external users or users without a license.
And the most important part: if any site owner selects “Don’t show me again” it will stop popping up for all other site owners. If you happen to have a manual step in the group creation process, then you can just click it away.
“Don’t show me again” option is per site, not per user.Internally, it is stored as a web property on root site of a site collection.
How to hide Teamify programmatically
Allright, if you still want to hide this prompt and you want to do it programmatically, you need to ensure that this web property is on every site collection root site.
Iterate through all sites
You can find a script for that on Microsoft Fasttrack github repository:
Performance and need for re-run. It iterates through all existing sites, meaning that it takes time to iterate through all of them and it requires that you run it again. In an organization with many new collaboration sites it might be a bad option.
Access to all sites. It requires SharePoint Admin, which is okay-ish, but it also requires that this admin account has access to all sites, in order to update the web property, which is not a good option when admins have a restricted access to actual sites due regulations.
CustomScript. CustomScript is disabled by default for a reason. Because it is a security risk. At least you should alter the script to reset the CustomScript setting on a site after you have changed the web property.
Hide Teamify site by site
You can of course hide the Teamify Prompt on a site without iterating. It is the same principle, but it doesn’t require iterating through all sites. You still need to be a SharePoint Administrator (or a Global Admin of course) in order to enable Custom Script. As in the case with all sites, you should reset the CustomScript to what it was.
Use GroupSiteManager Api
There is a new SharePoint Site API that you can call to hide a Teamify Prompt. All you need is to use the solution described in this sharepoint stackexchange answer:
This still requires that access to the site, but you will not need SharePoint Admin, nor will you need to change any CustomScript settings on a site. That’s better.
Calling PnP Rest Call to hide the Teamify Prompt.
Summary
There are ways of hiding the Teamify Prompt on a site collection. If you do that you should include that step in some provisioning process, and not iterate through all sites. It is better to not alter the CustomScript settings at all. First of all it is best to ask yourself why you should disable something that is done for users and for a better user adoption. Also consider that usually only few will be shown that (group owners with a license and within the organization). The group owners can also hide it by clicking “Don’t show me again” and it will disappear for all other group owners.
First, enable a Managed Identity for your Logic App:
In the KeyVault, add a new Access Policy for the new Managed Identity (from the previous step). Use the least priviliges. In my case it is just enough with GET for secrets.
Instead of filtering values from an Azure Storage Table, you can do it directly in the bindings. It might not be a solution for everything, but in the right place, it is fantastic. I was very surprised to see how little code was needed after this binding change:
For that to work, define the filter attribute in the bindings: “filter”: “(PartitionKey eq ‘{package}’)”
To try it out, add a new row in a table defined in the bindings (“metadata” in my case):
Start the function app and navigate to your function:
Just a quick tip today. I hope this helps you in your work. The raw material comes from stackoverflow:
Site Collection App Catalogs are great for special cases (like developing apps or site unique apps), but using them on scale would be a mess.
I got a question: Why should we use the Tenant App Catalog at all when we could enable a Site Collection App Catalog on every teamsite? So the suggestion here is to install SharePoint Framework Packages on many Site Collection App Catalogs, instead of the Tenant App Catalog. In that way those wouldn’t be visible for all users in the “Add an app” page.
Technically, both ways are possible, but I would say, we should use the Tenant App Catalog for apps that are installed on many sites. I have gathered some pros and cons to help people decide.
But first, some abbreviations and notes on terminology:
SCAC = Site Collection App Catalog, (Local App Catalog)
TAC = Tenant App Catalog, (Global App Catalog)
App = SharePoint Framework Package, but also a SharePoint Add-In
Pros and Cons of Site Collection App Catalogs
đ A SCAC makes it possible to have local instances of an app. It is perfect if you want to test an app without making it visible for the whole tenant. It is also good for apps that are only installed on one site collection. There are benefits of distributing site specific apps through the TAC, such as better governance, once installed on a site, those apps can be Disabled.
đ Mess in all the apps and the versions. There might be different versions of the apps. The update procedure will require a special script to find all the sites and run the update. This also requires owner access to that site. If the owners would like to remove all the IT accounts in order to collaborate on confidential information, then it wonât be possible to update that site. It will lead to poor governance. Just to give it a perspective. Imagine that every smartphone had its own local App Store/Google Play. Possible but counterproductive.
đ A SCAC is a security risk. The control and governance is handed over to site owners. It means that they can install any apps on their site collections. Poorly designed and implemented apps can lead to big security issues, in the similar way as custom script.
đ Enabling a SCAC adds additional lists and features (such as Apps for SharePoint). It will require more space (not so much, but still), but first of all it will make some users more confused, actually more confused then some more available apps. Imagine all the support: What is it, Oops I deleted “Apps for SharePoint”.
đ Every app will install the resources on every site collection, meaning every app will have multiple copies of the same app. It means more space needed. That is of course, not the case if you use Azure CDN.
đ Every app will use its own urls to resources, preventing browsers from gaining performance by caching the resources cross site collections.
đ If Azure CDN is used, you must make sure all the versions of javascript and css files are kept because you might not know which versions of an app are still used.
Pros and Cons of the Tenant App Catalog
đ Easier to control the apps and have better governance. The Tenant App catalog tells what apps exist in your tenant. As admin you can verify that the code complies with the guidelines (by running code checks), you can make sure, every app there has all needed information such as app owner, description etc.
đ Easier to update apps. Installing a new version of an app will update all the instances. There wonât be any custom script to traverse all the sites with that app.
đ It is more cost efficient to follow the Tenant App Catalog approach, because it is the recommended way of installing and updating apps. Having scripts and procedures for SCAC, (even completely automated) will always cost more: to keep the scripts up to date, support etc.
đ Benefits of the common apps. If a business unit comes up with a good solution, it can be used by other Business units, if it is discoverable and follows quality guidelines (more on that later).
đ The Apps from the TAC are visible to all Business Units and the users might be confused. This issue can be mitigated in two ways:
The business units that have not rolled out SharePoint Online and donât use any apps, can remove their users from the App Catalog.
Having a good naming policy, app icons, good descriptions, disabling any “auxiliary” apps. On top of that, some user guidance.
Summary of pros and cons
To summarize, Site Collection App Catalogs for reusable apps installed to many site collections, is a bad idea, because it means a security risk, less control and governance, encreased data and traffic to SharePoint Servers.
How can we scope apps to our business units
Are there other ways of scoping the apps to business units other than misusing the Site Collection App Catalogs?
First of all, it is a question of user adoption. It is better to help users instead of breaking the functionality or misusing other concepts.
Second, it is a question about governance of the Tenant App Catalog. It should be clear how an app can be added, and how that package should be wrapped:
good naming standard,
proper localization
a mandatory icon,
good description,
owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.
A couple of apps from your organization is a drop in the ocean compared to SharePoint Store Apps
Control with Permissions
If you remove a user from the Tenant App Catalog, the apps will disappear for that user.
There are apps, but this user cannot see any apps to install.
The permissions can set on the whole Tenant App Catalog by removing “Everyone except external users” and then adding all AD Groups who should see the apps.
The permissions could also be set on the specific packages or folders.
The permission way of scoping the apps might work. But it is important to know that it is a workaround and it breaks the default setup (where all users have READ on the TAC). This means that along the way you can bump into limitations or bugs, more or less unique to your organization. It will be harder to get help from Microsoft or from community.
I uploaded my app to two site collection app catalogs. Do I need to get approval for the app twice? â No.
I have got my approval for Delegated Groups.ReadWrite.All for App X. Now I want to use the same permissions in another app, do I need a new approval? â No.
The steps described in these guides are easy, but that effort made me think about the first pair of pros and cons.
A pipeline variable is faster to configure
A variable in a pipeline takes zero time to set up. Also, A secret variable remains as a secret, since no one can read it in plain text. To configure the Key Vault way of getting secrets requires admin time. Unless you have Admin rights in your Azure Active Directory and your Azure Subscription, you might need to request and argument for one or more of the following:
A service principal (an App registration) with a secret.
An Azure Key Vault (and maybe a resource group) with an Access Policy for the service principal
A service connection in your Azure DevOps Project
Of course, most of it is one-time-job. But still, in many organizations it will require good preparation. The pros for an Azure Key Vault secrets in a pipeline is that
Admins can manage the secrets centrally from Azure
Set it up once and let Azure DevOps people use it and re-use it in many pipelines, but still you need to set up a new Service Connection in every Azure DevOps Project
The fact that it is easier to reuse lets me think of my second pair of pros and cons.
A pipeline secret variable is more secure
Let’s say you need a password to a service account that will upload something important, e.g. an account that will upload a new SPFx package to the SharePoint App Catalog.
Doing it the pipeline variable way means that it remains as a secret on that particular release pipeline. Only release administrators of that project can alter the pipeline steps. No one else.
Doing it the Key Vault way, means that you must watch out on every part of that chain:
Users who have access to the Key Vault in Azure.
Service Principal that can read the secrets through access policy. Who has access to the secret?
Service Connection in an Azure DevOps Project. Who can use this Service Connection – to add and modify release pipelines? By default, all Release Administrators can do that. To do it more secure, you need to limit the count of Release Administrators. But it means less flexibility in a team and more admin effort for the allowed Release Administrators.
Also, the service principal used for getting the secrets and in the service connection, should not be reused across projects in Azure DevOps. Dedicated Service Principals will make it more secure because misuse can be more easily discovered and stopped – and thats on a project level, not for all service connections.
Summary
In flat small organizations, using a Key Vault for using secrets in Azure DevOps Pipelines is great, it saves you time. But it is less secure, and requires time and effort for an appropriate security.
Recent Comments