Have you had a PowerShell script that contains two bigger arrays and you wanted merge the information. It can become quite slow if you need to search for every item from array A through all items in array B. The solution is called a HashTable! It might be not an advanced tip for some, but I was really glad to see a huge improvement, so I decided to share it as a post.
My Array A ($sites) is a list of SharePoint Sites (over 10K of them). For every site I need to get information on the owner (such as UsageLocation). In order to minimize calls to the server I want to reuse the information – in my array B: $users. This array of users has also thousands of entries.
For uploading and deploying SPFx packages I found these permissions to be the bare minimum:
Delegated Microsoft Graph User.Read
Delegated SharePoint AllSites.FullControl
The second part is the service account that just has access to one site collection – Tenant App Catalog. That plus Delegated AllSites.FullControl of the app registration narrows the access to just that site. To install apps the Uploader Account needs to be Site Collection Administrator.
In our project we use Azure Pipelines where we also define the release using .yml. The deployment consists of series of bash inline scripts.
I am not going to describe all the steps for setting up node, npm and installing the office 365 cli. If you already have used Office 365 CLI with the default AAD APP it might look like this:
– task: Bash@3 # login
displayName: "Login to O365 spAppCatalogSiteUrl with user $(username)"
That’s straight forward when you run the cli in your own console. But the fact is (or at least from what I can see), you cannot “export” variables to other pipeline tasks.
Instead of setting the variables in the inline script, we can take advantage of the Bash task parameter called env:.
Some other findings:
Office 365 CLI needs them in all three commands: login, spo app add, and spo app deploy
If you create and export a variable in a pipeline task, it won’t persist, because every task starts a new shell session.
That means that we need to provide environment variables in every task in the pipeline, that uses Office 365 CLI with a custom Azure AD App. Or is there a better way? Anyway, the version below (the same tasks plus `env`) will work:
– task: Bash@3 # login
displayName: "Login to O365 spAppCatalogSiteUrl with user $(username)"
Honestly, Power Automate is great for automating repetetive stuff. But I think there is room for one-time flows as well. I’ll give you an example.
I’ve got an excel file with quite a few rows. And I need to convert it to a SharePoint List. I know there is a couple of options, such as Quick Edit in Classic View, Import an Excel file as a list (it also requires the classic view), there will be Excel import in Modern as well. But I need to also change the column names, maybe adjust something “on-the-go”.
But today, I find it much faster to set up a Power Automate (No worries, there is still need of “real” scripts and applications).
So my spreadsheet has two columns.
I create a new SharePoint List and adjust the columns to my needs.
After that I set up a very simple flow.
I could have loaded that excel, but I just pasted the rows directly in that flow. Hey, I will only run this once!
A positive side effect is that I also get a verification of the user accounts (my second column)
Since it run in an “Apply to each”, it keeps working even if specific rows fail.
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)
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
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.
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.
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
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.
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.
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.
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.
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,
a mandatory icon,
owner/contact person. Also, only relevant apps should be “Enabled”. All the other apps should be Disabled.
Control with Permissions
If you remove a user from the Tenant App Catalog, the apps will disappear for that user.
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 got my fingers and tried that guide out. This worked good, I spent some time, though, googling (binging) around to get rid of the SSL Warnings for the remote “localhost” on my Mac.
I would like to share this simple instruction on how to trust a self signed certificate from gulp-connect on Mac OS. The implication is that the certificate is on the remote linux machine (on the Visual Studio Environment), that you are connected to through the Visual Studio Code extension.
The first step (after you have connected and set up a project) is to download the certificate. It can be found in the following directory: