Planner’s Odd Attitude to PowerShell
I really wish a proper PowerShell module existed to manage Planner. If the Power Platform people can create a module to control the settings for self-service purchases, it’s not beyond the wit of the Planner team to create a module for its settings.
The problem has existed for a long time. Back in 2018, Planner introduced the capability to synchronize tasks with Outlook using an iCalendar feed. The Planner team also gave tenant administrators the ability to block the feature. It was clunky and horrible.
Planner Makes PowerShell Easy. Or Maybe Not
Three years later, Planner hasn’t delivered many other management settings for tenant administrators, but when it does, the same approach is rolled out. There’s no UI in the Microsoft 365 admin center. Instead, administrators get down and dirty with PowerShell to:
- Download a Nuget package containing the Microsoft Active Directory (ADAL.NET) class library and other bits.
- Rename the file to be a ZIP (which it is) and extract all the files to a suitable location on the PC.
- Make sure that all the DLLs are unblocked (through file properties).
- Create PowerShell psm1 (script module) and psd1 (module manifest) files by copying code from a web page.
- Import the script module into a PowerShell session.
- Run commands contained in the script module.
It’s a boring process that the Planner team should fix to make it easier to manage their app settings in a regular PowerShell module published in the PowerShell gallery. For instance, it would be nice to be able to define a default set of labels (now that a plan has 25 labels to play with) or define a default background for a plan instead of letting Designer do its best. But no, Planner and PowerShell is a total mess undermining the intention of PowerShell to make it easier for administrators to accomplish tasks.
New Roster Containers and Plans Coming in April
Normally, I avoid this kind of messing around and leave it to people with more patience and available time. On this occasion, the announcement in message center notification MC242586 (March 3) of “Planner’s New Roster Containers” brought me down the sorry path to PowerShell hell.
According to the post, a roster container is a plan created without an association with a Microsoft 365 group. It’s an awful name that I hope Microsoft will change before the software is available. I assume the roster is the membership list for the container which replaces the Microsoft 365 group.
No UI is available to create a roster plan within a container, but a Graph API is due to be enabled in all tenants on April 5. If enabled, anyone in a tenant can create a roster plan and define its membership. Any member can add or remove other members. The resources belonging to a Microsoft 365 group like a SharePoint Online team site aren’t available to roster plans, which seems like they inhabit their own world.
Although Microsoft doesn’t say how they plan to use rosters, it’s easy to see how this might be useful for Teams shared channels. Unlike regular channels or private channels, both of which depend on Microsoft 365 group membership for access, shared channels use federation to allow individual users and other teams to collaborate in a channel. A roster-based plan would allow a shared channel to include a plan.
Update: Microsoft posted on April 14 to say that they will not be moving forward as planned and will announce a new approach once they have considered feedback received from customers.
Disabling Roster Plans
Microsoft warns that disabling roster containers means that a tenant won’t be able to take advantage of some upcoming Planner features. Given that they don’t say what those features are, the information is not all that helpful. You can therefore disable roster containers until you understand what the new features are and if they are needed by the tenant.
This is when we need to re-enter PowerShell hell and follow the instructions to download code, create a PowerShell module, and run some cmdlets. All of which makes a task which should take a minute or so last much longer, especially when the documented instructions to set the Planner configuration are incorrect (Figure 1) and authentication is required before running each command. That’s a particularly charming and unique aspect of Planner’s approach to PowerShell.
For now, I have disabled roster containers on my tenant. I’ll review my decision when I hear more about how Microsoft plans to use roster containers and if necessary, I’ll go through the process again to enable rosters again.
Keep up to date with the important changes in Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. We’ll tell you when it’s safe to go back into the torrid waters of Planner PowerShell among other more interesting topics.