I have been working with a large government department where Microsoft Services helped them transform their intranet to SharePoint Online leveraging all the modern capabilities available as well as rethinking what an intranet was. This work included envisioning to fully exploit all of Office 365 and a crucial Information Architecture (IA) design which also mapped their existing, complex and poorly performing hierarchy of subsites to several new hub sites and a completely flattened site structure. I hope to write more about this work soon.
Primary intranet site navigation provider
To create a consistent user experience, the look and feel for several hub sites was replicated, creating the feel of a single intranet. The hub site navigation also needed to be replicated, and that is wherein the challenge lay. The navigation cannot be easily copied from one site to another, let alone between hub sites, and thus this solution was born.
We decided to create a dedicated hub site that only the intranet team can access. Within this hub site, we were then able to create the intended intranet navigation and get the headings, order and links just right without troubling anyone. Once we were happy with the navigation and testing successfully passed, the idea was that we would be able to replicate the hub site navigation to all our other hub sites. More importantly, the process could be easily repeated, keeping the intranet navigation updated across many hub sites. The task could also be automated but we opted to leave it as a manually initiated task.
Script to replication hub site navigation to other sites
The solution to the problem is a PowerShell script made up of two functions. One function that gets the navigation from the hub site acting as the master or primary navigation provider (supplied from a parameter). The other function replicates the navigation to other hub sites. The Get-SPOHubSiteNavigation function exports the hub site navigation from the site provided to a CSV file. The CSV file is then used by the Copy-SPOHubSiteNavigation function to replicate the navigation links to other sites. The process could be hijacked somewhat to add hub site navigation from a CSV file rather than reading it from an existing hub site. We found it was easier to get a feel for the navigation in a real SharePoint site rather than work with the information in a spreadsheet.
You can also disable the export process by setting the -Export parameter to -Export:$false. This switch makes the Get-SPOHubSiteNavigation quite useful for displaying the hub site navigation in an accessible collection. This collection can be used with pipe functions, to filter or sort the collection, for example. This collection is also much easier to work with than using the Get-PnpNavigationNode -Location TopNavigatioBar -Treecmdlet and parameters to show the full navigation structure.
As with many of my posts, I like to share any observations I have made during the work.
The cached Hub navigation appears to refresh every 30 minutes if left unchanged. You can force the cache to refresh by editing the links and then clicking cancel.
A JSON file gets saved to the /_catalogs/hubsite library which could be related to the cached navigation. It has a GUID based name e.g. 20d31c78-8a8c-499a-b953-ecc673344cef.json and appears to get modified by the System Account when changes to the hub site navigation are saved.
The cached JSON file looks like this:
This JSON file, in theory, could be read from a source site and the navigation element copied and injected into the JSON on a target site through manipulation of the JSON payload and the /_API/navigation/SaveMenuState API.
When trying to add a new navigation node using the Add-PnpNavigationNode cmdlet. If the parent node was invalid I got the following error. This wasn’t because the URL linked to a file or folder that didn’t exist as the error below suggests.
The script could benefit additional error handling, particularly to ensure the target site(s) provided are registered as hub sites.
Bonus tip! If you find you have lost changes to the navigation, this same JSON file is part of a library where version history is enabled. This file appears in hub sites and sites associated with a hub site. The version history might help you recover from any loss, but you won’t be able to restore it as the library appears to be read-only.
I hope you find this post useful. As always #SharingIsCaring
I’ve been working on a modern intranet project amongst over projects for the last 12-months. This has been more about the transformation of content and business processes, rethinking information architecture and reimagining a modern intranet than it has been about custom development.
We’ve recently been testing variations in the design of a homepage with different audiences. This side-by-side comparison has allowed end-user feedback, performance and accessibility testing. The same approach has also been useful for previewing and testing the capabilities of new features (like the new Yammer web part). The challenge comes when you need to promote or switch over one of these variations as the new site homepage. The homepage is the page users are directed to when first navigating to a site or clicking on the site logo. It is like as important as the index.html or default.aspx page existence to a website. Note that these variations of the homepage permit testing of content and not site configuration. To test navigation, theme or similar we have separate sites and environments for this purpose.
To solve the problem switching the homepage from an existing page whilst preserving the home.aspx page name I’ve leveraged the SharePoint Pnp cmdlets to create a script that will rename or remove the current homepage (and can remove it through a toggle) and then rename an existing page to make it the new homepage.
Use my PnP PowerShell script to replace the home.aspx page
Change the default homepage through SharePoint
Site Owners can use the out-of-the-box make homepage action to make any page the default homepage or welcome page. This is available from the toolbar in the site pages library. But this keeps the page name and means the default page is /sitepages/randompagename.aspx instead of the standard /sitepages/home.aspx that all sites have. From my perspective this is not great. Certainly, intranet-like sites should follow some basic content management principles. Call in a touch on the OCD side but consistently having a standard homepage is one of these for me.
Change the welcome page site property through Site Settings or PowerShell
Previously you could use the classic settings page (typically exposed by the publishing feature) or by browsing to /_layouts/15/AreaWelcomePage.aspx to make changes to the welcome page. This method no longer works and throws an error.
As with the make homepage action describe earlier this changes the default homepage to the use the page name you have provided and means the site won’t be available if users have bookmarked the site with the page name (/sitepages/home.aspx) in the URL.
What is my point? To this day can I still memory recall core settings pages. With these, you can quickly review or makes changes to settings pages rather than using the UI to navigate to them. This includes those that may no longer be exposed in the UI. Whilst my memory serves me well I don’t recommend this approach as these pages and settings are gradually being replaced with alternatives or removed by the SharePoint and Office 365 engineering team for a reason.
Instead, you can also use Pnp PowerShell to change the site welcome page property. I’ve provided an example script below.
As simple as my script is, it is the approach worth learning the most. I hope you find this article useful and as with all Pnp development effort. Sharing is caring!
A challenge for most administrators managing more than one or more Azure subscriptions or Office 365 tenants having to continuously log in and out with different credentials to do so.
Many have developed techniques to work around this challenge by using Incognito Windows or Private Browsing and others use multiple Browsers. Even with these methods, you are still limited to using two accounts particularly with Incognito Window or Private Browsing technique.
In this post, I share my method that enables you to log in to multiple Office 365 & Azure accounts in the same browser, on the same device at the same time!
Here’s an example of how many accounts I toggle between:
Microsoft Account for Corporate used for Azure Management Portal, Intune, Visual Studio Online and MSDN
Personal Office 365 account
Multiple Customer accounts (or through Delegated Administration using my Corporate Office 365 account).
Multiple Developer Office 365 accounts
Multiple Demo Office 365 accounts
Sure, a password manager might help with the login process by storing credentials but this still doesn’t solve the challenge of being signed in to multiple accounts at the same time.
The technique I have started using is a feature available in Chrome. Chrome allows you to create multiple user accounts from the Settings page.
I’ve created users for each of the Microsoft accounts I commonly use. Each Chrome user has its own settings such as the plugins installed, the bookmarks that are available, browsing history and the crucial part cookies and Browser sessions.
Now when I want to jump between Azure subscriptions or Office 365 tenants I can toggle between Chrome users. The user menu is available in a number of places.
Chrome Users is also available on the PC version of Chrome. I hope you find this technique of switching between Azure or Office 365 accounts useful.