Tuesday, January 28, 2020

Peculiarity with Hub sites - SPFx Header displayed state of associated site is initial preserved

Following information architecture situation:
  1. A communication site registered as hub site
  2. Another site (can be communications or modern teams site) associated with the hub site
  3. The associated site has some site info tagging; which is visualized to site visitors through a SPFx Header extension
  4. The hub site either does not have site info, or the values that it has are different from that in the associated site
Effect of this situation is that when one navigates within the hub association from associated site to hub and vice versa, it can in its (cached / preserved) header display false / incorrect information...

Site associated with Hub; in this site via SPFx Header extension, some ‘site identification’ is visualized in the site’s header

From this hub-associated site, navigate to the hub site. The header info remains visible, even though the info does not hold for the hub site

Refresh / explicit (first)visit the hub site; then the ‘false-positive’ site info is gone

From first visit of hub, navigate to the associated site. The header info remains invisible, even though this site holds identifying site information

Cause: in an hub, only on 'first-visit' the SPFx Header(s) are executed Inspecting the network traffic, it is evident that the displayed header info is not refreshed on navigating 'within hub context': the SPFx Header is not re-executed. Apparent only on explicit 'first-visit' to an Hub assocation - hub or associated site; then SPFxHeader components are executed. And on any navigation 'within' the hub; the (visual) state of the SPFxHeader is preserved; on same notice as the 'hub navigation.
For performance perspective, makes sense. But in situation where via SPFx Header extension essential site information is displayed, -- which is not per se similar throughout the entire hub association; the result in browser is functional / governance-wise incorrect.

Tuesday, December 24, 2019

Select the right Microsoft 365 Live Events type best fitting your needs

Microsoft 365 includes 3 different options to execute Live Events: via Microsoft Stream, Microsoft Teams and Yammer. The 3 have their similarities, and also their differentiatiors. How-to select the Live Event type aka webcast solution that best fits your needs on a specific event? Microsoft itself does not really provide direction on this question, although they published how their own Core Services Engineering and Operations (CSEO) team deals with it:
A different angle you can utilize is to address it from the product side...
Use MS Teams Live Event, if:
  • Your event audience is for public anonymous access;
  • Your event audience includes external guests known in your Office 365 directory (via Azure B2B);
  • Your event audience is for internal-only access AND you want to provide an inline conversation;
  • It is allowed that the video recording is not stored in your own Office 365 tenant; (see)
  • Your audience is guaranteed known before the live event starts; (see)
  • There is no need to capture the conversation (Q&A) beyond the scope of the live event
Produce your MS Teams Live Event by:
  • 'Self-production' / embedded encoder via MS Teams, if
    • You want to quickly setup the event, and have no requirements for advanced production quality (as animations, fade-in/fade-out; agumented reality, ....);
    • You as event organizer are confident to do the event production (camera, audio, PowerPoints, ...) yourself;
  • Use 'External App production' via MS Teams, if:
    • You need advanced production quality to bring the message;
    • You're not confident to do the production yourself in MS Teams App;
Use MS Stream Live Event, if:
  • Your event audience is for internal-only access, AND
    • you want to broadcast / send a communication message
    • your online audience size is larger, and you must protect your network from saturation via an eCDN solution
  • You want a branded landings-page for the audience to join the live event;
  • It is not allowed to store on-demand recording of the live event outside your own Office 365 tenant; (see)
  • You need to be able to on-the-fly while live event already in progress, authorize + revoke authorization of persons to watch the live event;
  • You want to easily capture the conversation (Q&A) beyond the scope of the live event; e.g. for trends analysis;
A variation on decision-tree to select proper live events type
Check / Differentiator Questions
  1. What is the audience of your event: internal-only, or also outside your company? (with MS Stream not possible current>)
  2. What is the size of your online audience? (as with larger, network optimization needed)
  3. How sophisticated do you need the production quality of your event to be? (is the simplicity of MS Teams Live Event 'self-production' good-enough)
  4. Do you have dedicated production equipment, or even a production company to produce the event via external encoder?
  5. Do you need to provide a company-branded experience to join the live event?

Monday, November 25, 2019

Beware: unique library permissions breaks drag-and-drop capability (classic site)

Breaking permissions is advised against, unless... Main rationale for this generic rule of thumb is the complexity that unique permissions brings to permission management in a SharePoint site. However, in addition it can also have a limitating effect on the user experience: persons of which the authorization in a site is limited to only contribute in a specific document library, face issues on upload of documents. Quick investigation revealed that the problem occurs when the document upload is done via drag-and-drop; uploading a document via the explicit 'upload' UI flow does succeed.
On SharePoint platform level, these functional equivalent actions are executed via other flows. In the drag-and-drop scenario, SharePoint executes a CSOM call to read the site properties. But if a person is only authorized to the document library, the 'SelectAllProperties' processQuery action on SharePoint Site level returns 'Access Denied'. Solution is to grant the persons also a limited permission level on the site level, so they are allowed to read the site properties.
With this ‘Read Site Props’ permission level granted at site level, the respective persons are still correct blocked to access entities and content on site level; except for the library to which explicit granted via unique library permissions.
Noteworthy is that the issue does not occur in modern sites, even although also in that context with 'drag-and-drown' execution the site properties are retrieved via CSOM call.

Friday, October 18, 2019

Beware: immediate after upload into Stream, video is available in only 1 quality / rendition

A business user recent approached me with question why his uploaded video was only available in one, and not the highest bitrate / quality in Microsoft Stream. However, when we opened the video to inspect, he was pleasant surprised that all of a sudden the video could be played in more qualities, including with higher bitrates. This behavior is completely explainable, as on Stream side processing takes place to convert the uploaded video in multiple bitrates; and that processing simples takes its time to complete. But it is good to be aware of, and realize that you just need to be a bit patient for the different video qualities to become available.

Sunday, October 13, 2019

Beware: Open Project Online resource in 'Edit Resource' blocks the automated modification of that item

The Project Online ResourcePool can be automated managed, e.g. to update a (Custom)Field of an EnterpriseResource. Something that I became aware of is that the automated modification is blocked in case the resource is opened in 'Edit Resource' of the Project Online Web Application (PWA). Apparent PWA applies defensive locking, and already immediate locks the resource through checkout when opening it in the form, and not delayed / just-in-time at the moment of possible save. The automation is blocked both when doing the modification via ProjectServer REST service, as when via the ProjectServer.Client CSOM library.
Open a PO resource in the ‘Edit Form’
(<pwa-url>/_layouts/15/PWA/Admin/AddModifyUser.aspx )
Automation code-snippet to modify EnterpriseResource via REST service
 $body = "{ 'Name':'Test Name', 'Group':'Test Group' }";
 Patch-ReSTRequest $pwaUrl "ProjectServer/EnterpriseResources('$resourceId')" $body
Combination of 'Edit form' + automation execution results in error
       "code":"10101, Microsoft.ProjectServer.PJClientCallableException",
              "value":"PJClientCallableException: CICOAlreadyCheckedOutToYou"

Sunday, September 29, 2019

Be aware: join as MS Teams Live Events guest requires that one is pre-authenticated against the inviting tenant

With MS Teams Live Events produced via Teams (aka QuickStart) it is already supported to invite externals (MS Teams produced via External App will support it once the underlying Microsoft Stream Live Events capability supports guest access). Guest access in MS Teams Live Events by Teams is realized by utilizing the Azure AD B2B capability, similar as is done in the external sharing of a MS Teams instance itself with external guests, and also in external sharing SharePoint Online sites. Interesting is that the external does not need to be invited to any MS Teams instance of the inviting company. This makes sense, as a MS Teams Live Events instance itself is not tied to a particular MS Teams instance; it is scheduled from the MS Teams Calendar.
Guests can join the Live Event via the browser or via the MS Teams App. In case of the latter: In your joiner instruction to invited guests, please make sure to inform them that they first must authenticate themselves against your (the inviting) tenant, before trying to join the MS Teams Live Event via the distributed 'attendee link'.
No permission to join as guest in case not authenticated before
Authenticate as Azure AD guest to the MS Teams of the inviting tenant; first authentication is 'federated' against the invited guest identity administration, and next most likely second / multi-factor authentication against the inviting tenant
Once authenticated as AAD guest to the inviting MS Teams tenant, allowed to join the invited Live Events direct via the 'attendee link'

Saturday, September 21, 2019

In the dungeons of Azure AD B2B: properties of external Azure AD account might block creation of guest account

Collaboration between organizations in an ecosystem has become more and more essential to the value organizations create. But also in these Business-2-Business (B2B) collaboration scenarios, the authorization principle of 'need-to-known' must be adhered: employees from the partner organizations should only be granted access to the information on which they actually collaborate with the inviting organization. To be able to grant selective authorizations to the externals, requires that each of them must be known with identifying identities in the information system(s) of the inviting company.
In the Azure AD B2B model, Microsoft introduced the notion of 'guest accounts' for this, based on the concept of "bring-your-own-identity". An Azure AD B2B guest account is a lightweight account, that in fact acts as placeholder in the Azure AD context of the inviting organization to external identity managed outside the responsibility of the inviting organization. As such, Azure AD B2B collaboration supports cross-company relationships by enabling partners to selectively access your corporate applications and data using their self-managed identities
Azure AD B2B supports 2 modes to invite external guests via their corporate email addresses: a federation model from the Azure AD of the inviting organization to the external Azure AD of invited partner organization. And in the case that the invited company is itself not (yet) an user of Azure AD for their identity management, via just-in-time created accounts which are then administrated in a so-called 'viral' tenancy (see: Understand the B2B user).
Guest accounts are created in the inviting Azure AD with their own (external company) email address applied as their guest account / identity name. Azure AD requirement here is that the guest identity name is not yet in-usage as proxy-address within another account in the Azure AD tenant. The typical situation in which this could occur is when an external employee already has also a Member account in the Azure AD of the inviting organization, and has the own corporate email assigned to that Member account. When next you try to create a guest account for that external email, Azure AD refuses with error message: "The user you're inviting already exists in the directory. They can simply sign in into shared apps and resources."
The most pragmatic approach to fix this guest account provision error, is to 'free' the external corporate email address of the 'to-be AAD guest': disconnect it from assignment in the Member account in the Azure AD of inviting organization.
Another apparent feasible approach is to simple select another external corporate email as guest account name: e.g. instead of '<External>.<User>@>ExternalOrg<.com', provision a guest account via '<External>.<User>1@>ExternalOrg<.com'. This is certainly a creative alternative. But you need to be aware of some pitfalls with it. 1) Redemption in Azure AD B2B is an email-verified process. Meaning that the alternative corporate email address must actually exist and resolve to an email inbox in the domain of the invited organization. 2) In case of federated Azure AD tenants, the requirement that the proxyAddresses must be unique, is verified in the combination of the Azure AD tenants of both the inviting as the invited organizations. Resulting that in case to the alternative account in the Azure AD of the invited organization, the original corporate email of person is administrated in the proxyAddresses, then the provisioning of guest account in Azure AD of the inviting organization still blocks. See How can we improve Azure Active Directory? - Show the B2B-blocking proxy address in my tenant's logs where this is shortly described.
Code snippet to have run in the Azure AD tenant of the invited organization, to identify whether and which proxyAddress value is the cause of the blocking:

Get-AzureADUser -Filter "mail eq '<firstName>.<lastName>1@externalcompany.com'"
   -all $true |
Select-Object displayName, @{L = "ProxyAddresses"; E = { $_.ProxyAddresses -join ";"}} |
Export-Csv -Path C:\temp\ReportOutOnAADAccount.csv -NoTypeInformation