SharePoint Site Swap – an adventure for a party of medium to high level players

I spend an inordinate amount of my time reviewing the Microsoft roadmap and the many elements in the Office 365 Admin Center Message Centre; partly because there’s so much new stuff coming out all the time and partly because I’m a masochist like that.

Digital Workspace technologies is my sweet spot; I tend to read up on everything Microsoft is doing around that and play around with them as soon as the chance avails itself. I use this to incorporate the knowledge and features into our products & services and so I can keep our clients up to date (and keep us one step ahead of our competitors). I supplement this with my annual trip to the huge Ignite conference in the US, where I get to talk to some of the Microsoft programme managers and engineers and simultaneously attend every session I can squeeze in over the 5 days (I walked 74.5km during Ignite this year. In brogues). Invariably, I then spend the next couple of months frustrated that the new features that were showcased and promised aren’t available on our tenant for me to evaluate.

So, with considerable excitement, I noticed that the SharePoint Admin Center updates, described in the Ignite 2019 blog, became available at the end of November for us.

This is what the Message Centre announcement promised:

“Replace root site – You can replace your root site with another site from the SharePoint admin center. The original root site is moved to a different URL and can be restored, if necessary. This feature will only be available for limited customers. For more information, refer to Message Center post MC189866.”

 

Setting the scene “You are sitting in a bar when…”

With only mild trepidation we set about swapping out our internal intranet Classic Site (with a Modern landing page) for our shiny new Modern site linked to an ‘All Company’ Teams Area. This was something we had wanted to do for many months and looked like it was super easy. We used the new PowerShell cmdlet: Invoke-SPOSiteSwap, though Microsoft are promising a Swap site button in the SharePoint Admin Center.Site Swap

Using PowerShell, it was super easy:

  1. Connect to SharePoint Online as a global admin or SharePoint admin using the SharePoint Online Management Shell
  2. Run Invoke-SPOSiteSwap.
Invoke-SPOSiteSwap -SourceUrl https://contoso.sharepoint.com/sites/CommunicationSite -TargetUrl https://contoso.sharepoint.com -ArchiveUrl https://contoso.sharepoint.com/sites/Archive
SourceUrl is the new site you want to use, TargetUrl is the old root site you are replacing and ArchiveUrl is the location where you want to archive the current root site.

Watchouts – challenge rating 1

A couple of immediate gotchas that Microsoft publicise:

  • The source and target sites cannot be connected to an Office 365 group
  • The source and target sites cannot be connected to a SharePoint Hub site. In the latter case, it’s a fairly simple matter to remove the association, do the swap, and then re-associated with your preferred Hub. Note that this means that the root site need not be a Hub and can be a ‘child’ site (if you want to think hierarchically). Equally you can make the newly swapped root site into a Hub site; this hurts my head less, but it’s still useful that it doesn’t have to be the ‘parent’ n the relationship, just because it is the first thing that people encounter.

 

So, the site swap happens pretty seamlessly and without initial drama. We just let people know what we were doing and asked them not to mess with things for half an hour. We even provided a nice link to the old home site, which was now to be found at:

https://<mydomain>.sharepoint.com/sites/oldrootsite/pages/home.aspx

End of level boss encounter – challenge rating 9

It didn’t take that long to realise that we had made a mistake…

red cross of dreadThe first thing I noted was that a document I had open was warning that it couldn’t complete its autosave. Then I spotted the Red Cross Of Dread on my OneDrive sync client icon. The penny dropped…

When we designed our intranet, we valued interaction and sharing of content between sites over the competing view that everything should be a separate disconnected site collection. Consequently, almost everything was a subsite of our master site. This let us do clever things by referencing assets and lists etc. that were mounted at the home level. It worked very well for us for many years. Until we did a site swap.

What happened is this: all our department sites and their content had absolute addresses based on our old root site. So our Sales site, for example, was:

https://<mydomain>.sharepoint.com/TeamCentre/Sales/Pages/Home.aspx

Key documents, many of which we have pinned or wired up to buttons and navigation tiles, have paths such as:

https://<mydomain>.sharepoint.com/sites/Sales/Shared%20Documents/GCloud/O365Services.docx

All these instantly became broken as the post-site-swap address became something like:

https://<mydomain>.sharepoint.com/sites/oldrootsite/TeamCentre/Sales/Pages/Home.aspx

 

Even some of our webparts broke

web part broke

In hindsight, Microsoft did give us fair warning:

“The previously designated root site automatically gets archived along with any subsites that may have existed.”

We weren’t thinking ‘archive’ just new location, but the effect was the same.

Picking up the pieces, healing the injured

We are now enjoying a rapid re-architecture of the site (using the rather excellent Sharegate tool to promote subsites to site collections), while fending off the withering glares of our inconvenienced colleagues.


Learning from other people’s mistakes

I leave you with this helpful advice, in the hope that you cunningly avoid the boss level encounter (and still gain the experience points):

RTFM

Microsoft provides some pretty decent guidance here: https://docs.microsoft.com/en-us/sharepoint/modern-root-site. We really should have read it carefully and thought about it first. In our defence, we may have made the same mistake, since the only real warning was a single bullet point, hidden in plain sight under Limitations:

All subsites contained with the source and target sites will be swapped.

Restructure first

Subsites were always going to break, regardless of how much we read. Before doing the site swap, promote all your subsites to new site collections. You could just recreate them and copy the content across if your environment is simple.

Warn your staff of the pain to come

Favourited links, pinned documents, local sync, shortcuts, inter-document links; they are all going to die, horribly (except where you made them relative links). Prepare your staff for the pain, get your support desk doubly ready.

Remember people mostly have multiple devices, so the pain is multiplied (using Edge or the new Edge Chromium helped, as at least browser favourites synchronise across all devices).

Re-index

Make sure that you force the indexing process so that Search very quickly finds all the stuff in its new location – it’ll save your bacon when staff can’t remember where the things they linked to actually were.

Permissions and governance

Think about what permission inheritance might now be broken. It’s not just user permissions; any ‘up the tree’ references to master lists etc. are going to be in trouble.

Navigation

SharePoint’s global navigation is rubbish. It’s also very easy to lose sites as the only place to see every site collection is from SP Admin, and that’s going to be full of random Microsoft Teams sites etc. Make sure you document all your sites and design a replacement global navigation before you start (we were lucky; our navigation was embedded as a termset, plus we have a rather excellent global navigation megamenu we built for our Hadron product that we could simply update with the revised URLs).

Re-sync

You are going to have to walk everyone through how to fix their locally synced content, since all their synchronised libraries are now broken. Firstly, make sure that they DO NOT save anything to the local drive as they will no longer update to the cloud. They will also see a bunch of errors in the OneDrive sync client in the tool tray (bottom right). To sort those out:

  1. Open Windows Explorer and click the company’s Sync group, the one with the building icon. This shows the sync’d libraries in the right pane. Note any that don’t have a status icon as these are the ones that are now broken: Sync
  2. Open the OneDrive sync client settings (right click and choose settings). On the Account tab, click Stop Sync on the folders identified in step 1. This should remove the sync errors.
  3. Now go back to Windows Explorer and delete the folders

URL edit

Another new feature is the ability to edit SharePoint site URLs. This is handy when you find you have conflicting site names, probably because of Microsoft Teams again.

Page upgrades

Now that you have survived the site swap and dealt with the snagging, it’s time to ensure all your classic pages are converted to lovely, shiny (and fast) Modern pages. At Ignite 2019 I asked lots of Microsoft people and migration people (Sharegate, AvePoint et al) if there was any way to do page conversions. It was a resounding no.

This morning I came across this, just announced by Microsoft (post Ignite):

Transform classic pages to modern client-side pages

Automatic conversion of classic pages to Modern, via Powershell, .NET and (Preview) user UI. https://docs.microsoft.com/en-us/sharepoint/dev/transform/modernize-userinterface-site-pages

Maybe you don’t need to get a student in after all.

 


Please drop me a line or comment if you have feedback on this. If you just want to comment on the RPG references in order to reveal your inner geek then that’s good too.

 

 

 

Leave a comment

Filed under Intranet, SharePoint, Best Practice

Folders are dreadful. Teams is great. Teams uses folders. Discuss…

A while ago I wrote a (carefully considered) rant about the evil that is the Folder. I dislike folders so much that I wrote a song about them (well, part of a song, but in this I am definitely allowed artistic license.) Yet I am clearly on record as a bit of a Microsoft Teams convert, and Teams uses folders, not grown up metadata. See if you can spot what’s wrong with this picture…

“Microsoft Teams… the Saviour of the Universe (ah aah)”

If you have had any interaction with Microsoft of late, you would be easily forgiven for thinking that. While I am an ardent lover of the power, sophistication and flexibility of SharePoint, I would concede that it is a complex platform and it’s very easy to develop ‘bad’ solutions on it that do not get great engagement from staff (unless done really well, which is what we do in Cloud2, but that’s a different story). So complex that MS were close to abandoning it as even they didn’t really understand what they had created. Then Jeff Teper came along and painted a new vision and the SharePoint garden is flowering nicely; however, that doesn’t get around the issue that it is a serious application that needs developing into a solution before it can be used. I even wrote a blog on how SharePoint is like Lego, but that was long ago in a galaxy far away. Meanwhile some folk at MS were playing and invented what became MS Teams, which provides a really simple experience for users, combining team chat (like Skype for Business chat, but with Slack like persistence and for persistent groups of people), combined with a Files tab and some other useful stuff. But you knew all that, didn’t you? You probably also knew that the Files tab is actually a SharePoint library and the act of creating a Teams Area spins up a full, linked SharePoint site collection. Teams Areas can have additional Channels, usually orientated around a work stream, activity or sub-team and these also have their own Files tab. However, go exploring these in SharePoint and it’s quickly apparent that each channel’s files are simply in a folder in the SharePoint library, with the same name as the channel. You can add metadata, views, content types etc in the library as normal; however these resolutely fail to appear in Teams (unless you manually add additional tabs that point at the libraries). Instead, the only way to organise your files within a Channel is to create folders and these become sub-folders in the channel folder in the library. Following so far?

In Teams it’s all pretty simple; end users wedded to the noxious horror of folder structures can carry on regardless and no one has to train, encourage/threaten them to experience modern thinking on knowledge management (it’s only been 20+ years after all). Perhaps I’m being unkind; Teams is rather nicely pitched at the ordinary ‘Joe User’ who just needs to have a simple experience and do stuff quickly; there is nothing initially wrong with that. Except that these systems always end up growing to the point of dysfunction as more and more content is added; it’s a sort of Digital Peter Principle. Despite years of best practice, evangelism and dire warning about the issues of folders (and everyone’s’ personal experience of how badly broken all shared drives on file servers are), MS have created a brand-new monster. How we laughed.

 

One of the cool things about Teams, is that it is fairly extensible; you can add new tabs, link stuff together, use content from other applications via connectors; even fire up workflows and embed applications in tabs. You can also bounce people up into ShrePoint for all the sophisticated stuff about 20% of use cases will ultimately need. But if you allow your information architecture to be screwed up then it’s a nasty, soulless job to fix it for that 20%. What you really need is some way to bridge the gulf between a fast-adoption, simple-to-understand Teams experience and an enhanced, life cycle-managed, compliant SharePoint one. Your users (mistakenly) want folders, your organisation needs metadata.

This issue has vexed me for some time, until a timely conversation with the redoubtable Jon Burton about this exact issue (how he laughed). Being a kind soul, I like to not only offer things to fear, or be intrigued by, but also provide solutions to real-world issues. So, I present to you… ‘Content categorisation based on Folder names’

This is his not actually a new concept. In the Folders blog, I talk about how most folder names are really just a crude and somewhat ineffective way of categorising things. In fact one of our earliest clients, Paul Kendrick, bemoaned that Microsoft had no function that let users drop documents into folders and turned that into metadata. We have even used this concept in Hadron Migrate, our file system to SharePoint rapid migration tool. The trick, in this case, is to write a Flow. It works like this

It is triggered overnight or whenever new content is added to the Teams Area library.

It uses the Is Folder function to identify the Top Level folder name in the folder tree (which will be the Teams Area Channel) and use the Update function to write this into a Channel column in the library for each document.

It uses the same Is Folder name of the immediate parent folder of the file and Update that into a Category and/or Keyword column.

Before this we would deploy content types to the libraries that contain the required columns. We would also create a set of metadata driven views that are set to ignore folders  and show content Grouped by Channel. Filtered as needed

Until such time as Microsoft do provide full metadata and view support in the Files tab (it’s coming, they claim) then we would add the library into a further tab, to allow a rich navigation of content as required.

It’s pretty neat; combining the simple and sophisticated worlds. You could even use it in SharePoint without Teams being involved. How about having a Drop Off folder, that users can create their own sub folders in and the content is then tagged, moved, or otherwise processed. If you want to get really sophisticated, then we would use some cognitive services stuff to extract keywords from the document content and use that to further tag the documents. But that a different blog entirely (but like the one on autotagging images)

 

 

 

2 Comments

Filed under Collaboration, Content management, Office 365

Is Check in/Out still relevant in 2018?

The thing with blogs is that one tends to write about subjects that one is interested in, or even passionate about. Often this results in excessive evangelism, sometimes it can turn into a rant. It would be a stretch to classify this as the former (but if you want an unequivocal rant read what I think about Folders)…

SharePoint is a marvellous piece of technology, offering a massive breadth of tools and some especially neat ways of managing documents and other content. It also includes some legacy features which have become largely superfluous, but which some organisations cling onto, not realising how best practice has moved on. This blog considers one of these, Check In/Check Out, why it should almost never be used and the few occasions when it still has a role to play.

 

As with most things Microsoft, the level of integration between different elements of the Microsoft stack is outstanding, and it often seems that the entire suite of Microsoft products advances in strict lock time, each taking advantage of the new features of other parts. There have been notable exceptions over the years, or course, but that’s the subject of a future blog.

Frequently, the collective improvements border on being a revelation, if not a revolution; they offer the possibility of radically changing business processes and supplanting previous good practice with better practice still.

One such ‘aha’ moment was the introduction of multi-author editing into Microsoft Office, and especially Microsoft Word, using the capabilities of SharePoint and OneDrive to handle the streaming of document updates in almost real-time. This is such a brilliant thing that it’s hard to imagine a world without it. However, prior to its introduction 10 years ago, we were burdened with a world where we either emailed documents amongst people and hoped to reassemble them, painstakingly and not without error, from the arbitrarily edited and often conflicting versions; or else we did the smart thing and saved them into an early version of SharePoint so that we could all work on a single copy of the document. Best practice, back then, was to check a document out while you’re editing, this locked the document and ensured that we didn’t experience the pain of conflicting edits where someone else saved their changes over yours, eradicating hours of important work. However, best practice or not, ‘Check Out’ and ‘Check In’ are, much like folders, an invention of Beelzebub, historically necessary but deeply evil. They serve their purpose to protect the document from overlapping changes, but they do nothing to protect hopeful document editors from colleagues who check a document out, forget about it and go on holiday, usually for two weeks (often more in Europe).

Time and again, check out has been demonstrated to erode efficient editing processes and to create a real governance and compliance risk. Checked out documents cannot be further updated by others; when such updates are needed in a hurry (usually not long before an audit is due), the only recourse is to create a copy of the document and work on that. This practice deeply undermines the single-source of truth philosophy that should underpin good content management. Of course, you could call a SharePoint administrator and ask them to cancel the check out; but that’s slow, burdensome on the admin and inevitably means that whatever updates that the check-out miscreant had (lovingly?) crafted are lost.

Thankfully, we are living in a new decade, where multi-author editing is a standard feature of the Microsoft technology stack and operates so slickly and transparently that it’s a doddle to use and it’s comparatively hard to screw up. When using Word and its kin, you can see who else is working on a document, see which bits they are editing and see their changes appear almost as they type in most cases. You can even contact the other author directly from the document to clarify wording etc. or flag a point to them using an @mention in a comment. Documents are never locked, version control and version history ensure that previous versions remain accessible and roll back is simple if required, tracking of edits ensures enhanced visibility and review. It’s bloody impressive and major step forward in productivity and compliance, doubly so if you have a distributed team or ‘agile’ timelines.

So why, oh why, do some organisations still insist on using Check In /Check Out? Here are some thoughts, excluding the obvious “They are blithering idiots” option which I wouldn’t dream of putting in writing anywhere:

  1. A lack of active learning about the technology across the organisation has resulted in no one realising what the new tools can do. This is a shame, especially as you are paying for all those new features on an annual basis if you have a cloud-service subscription. Given that the technology costs can run to £manyhundredsofK for larger organisations it seems that a bit of investment in getting ongoing and increasing value from the tools would be wise.
  2. Inflexible culture might to be to blame; I do come across “it was good enough for my grandfather” organisations, where they hang on to the old ways because they were fine in the old days. However, I don’t see so many of these any more, since most of them have gone out of business. It’s a rapidly changing, hugely competitive world and organisations need to flex with it. Including public sector ones, who owe the tax payers a duty to spend money wisely.
  3. Inflexible processes, where it’s so hard to change something that has been written into a policy or procedure that only critical changes are pushed through. Actually, this is often another symptom of the culture and has identical outcomes.
  4. Someone in IT or the outsourced services department decides that Check In is the right thing to do, that it is somehow safer or better. I can think of a handful of scenarios where this is actually true. But the other 99% of the time it’s nonsense and professionals or consultants who are paid to know better telling organisations that they should base their policies on it should be a criminal offense (I would make it a capital offense, but I’m a liberal kind of guy and reserve that for only the most heinous of crimes, such as Folder abuse); or at least ground for renegotiating contracts.

 

The bottom line is that organisations should have Check In/Out turned off as the default position. Version Control is generally already on (almost certainly true already if you are using SharePoint Online) and every version of Microsoft Office from 2010 onwards supports multi-author editing which ensures that changes are seamlessly managed.

 

So, go and check all your libraries now and turn that option off. It’s in Library Settings, Version Settings. Think about your version control settings while you are there.

Version Control settings

If you think you might need to use Check Out then have a conversation with someone about the specific use case and see if you can really justify it. If you are stuck for someone to ask, drop me a line – but don’t expect an easy ride.

 

Leave a comment

Filed under Best Practice, Content management, Office 365, SharePoint

Microsoft Teams Best Practice

It would be fair to say that I have become something of a Teams convert. Maybe even an evangelist. With that in mind, here is a round up of what I consider to be some good and best practice for use with Microsoft Teams. Teams is so new that new features are emerging all the time and use cases and associated practice are also emerging, so any of this is subject to change.

  1. Turn it on! You can do this in the O365 Portal and you can assign licences to all users or a selection. PowerShell scripts can help if you need to be selective.
  2. Call each team in Teams the ‘Teams Area’ or ‘Area’ for short. The language gets really messy otherwise.
  3. Have a naming convention for each Teams Area. At the minimum this should include the owning department or function and the purpose of the Team, e.g. Sales – Tendersteams request flow
    1. Have a clear naming convention to differentiate between Live and Test Team sites. You could add -Test on the end or add an asterisk or other character to indicate temporary or test Areas
    2. It’s also useful to add the date it was created, so dormant Areas can be removed.
    3. Remember that each Area also gets an email address. Make sure these group addresses don’t conflict with existing email groups.
    4. If you need extra control, only let new Areas be created via a Flow, with approval. See the screen shot for what you might want to capture; you then need to use a Custom Connector (as there isn’t a direct option in the Teams connector yet), but there is a useful option already on Github for this
  4. If you want a SharePoint Site, but also use Teams then make sure that you create the Teams area first; it will create a group and a Modern SharePoint site for you.
    1. You can do it the other way and link a new Area to an existing site, but only of that site has a Group already.
  5. Ensure that someone reviews the range of Teams from time to time and ensures that they meet the naming convention, as well as removing dormant or duplicate Areas.
    1. Create a Flow to notify an Admin whenever a new Area s created
    2. Check that every Area has more than one owner, just in case one of those knocked over by a bus scenarios happens; or that the Area owner is on leave.
  6. Use Channels to separate out different workstreams, topic areas etc.
  7. Remember that there is currently security at the Areas level but not at the Channel level. Anyone in a specific team can see all the content of all the channels in that Team Area. Don’t share sensitive Areas; consider having a second Area for each external person or group you share with. Use the Move or Copy function to shift files etc between the two.
  8. Get to grips with tabs
    1. Remove the Wiki tab – it’s hopeless. Add a link to your own OneNote pages, tabs etc instead
    2. Add pages, applications and SharePoint libraries and Lists as tabs in channels, to create a joined up working environment.
    3. If you use Dynamics, read this: https://community.dynamics.com/365/sales/b/d365forteams/archive/2018/12/07/best-practice-using-microsoft-teams-with-dynamics-365
  9. Add metadata to the libraries (via the SharePoint site), even though it doesn’t currently appear in the Files tab in Teams. It will at some point and you’ll be glad you have the extra control, filtering etc.
  10. Learn about Guest access
    1. Guests users have a bunch of restrictions – make sure people (and your help desk) know about them: https://docs.microsoft.com/en-us/MicrosoftTeams/guest-access
    2. Remember that you can only have 5 guest users per real user – actively remove dormant guests from time to time
    3. An Admin can invite up to 2000 guests at a time, via a CSV file and using Active Directory B2B (https://docs.microsoft.com/en-gb/azure/active-directory/b2b/what-is-b2b)
    4. You need to turn on and manage Guest access:
      1. Sign in at Office 365 global admin portal; in the navigation menu, choose Settings and select Services & add-ins; Select Microsoft Teams;
      2. In Select the user/license type you want to configure, select Guest; Click or tap the toggle next to Turn Microsoft Teams on or off for all users of this type to On; Choose Save.
    5. Global admins can choose, who will be able to invite guest users to an organisation:
      1. Directory admins and users in the guest inviter role;
      2. AAD members;
      3. Guests.
  11. Don’t forget that every Area has an associated SharePoint site.
    1. Make sure users know how to easily access those; ensure that these sites are discoverable from within your intranet (i.e. add them to your navigation), and encourage Area owners to update and format their sites.
    2. It’s a good idea to create a SharePoint Hub site and associate all the Teams Areas sites to that hub.
  12. Establish some Chat etiquette. Area owners should help police this and remind users of the etiquette
    1. Use @name in a team chat to ensure someone gets a notification
    2. Always use Reply to add commentary to a thread
    3. Keep conversations focused in the right channel and Area.
    4. Don’t say thanks etc to every chat; you can hover over the chat and click the Like icon if you want to acknowledge someone.
  13. Consider setting up some policies for how Teams should be used
    1. Review the audit log for events etc. from time to time (https://docs.microsoft.com/en-us/MicrosoftTeams/audit-log-events); you need to turn it on though. It can tell you about:
      • Team creation
      • Team deletion
      • Added channel
      • Changed setting
  14. Get familiar with the Security and Compliance Centre, so you can check that you users are following the policy.
  15. Get users to learn the Search box. E.g. Type @name in the top centre search box to start a chat with someone
  16. Check out all the add ins and connectors – there are many. Take a view on which add value and provide guidance to staff on these.teams connectors
  17. Consider writing Flows to inject messages, updates and even email into the Chat streams in channels – you can probably reduce email by 10% or more
  18. ‘Favourite’ teams and channels for people, so that they can find the Areas they want more easily.
    • Try to keep the number of Favourites to no more than a dozen
    • Link to Teams Areas from SharePoint (and anywhere else relevant), especially for less commonly used Teams
  19. Consider keeping a log /directory of all your Areas.
  20. If you have less than 1000 staff, create an All Staff Area and use it for general communications etc. similar to how you might have with a discussion group or Yammer. Consider adding your Company News feed to a tab or as a channel
  21. Create a Feedback channel in the All Staff Area
  22. Decline to travel to meetings; suggest that they can be done via Teams instead.
    1. Ensure the New Teams Meeting button is enabled in Outlook for 1-click online meeting creation.
    2. Do the same with your clients
    3. Ensure users have access to headsets.
    4. Consider using video too
  23. Turn off Skype for Business

 

 

Find out more:

https://docs.microsoft.com/en-us/microsoftteams/best-practices-organizing

https://docs.microsoft.com/en-gb/MicrosoftTeams/Microsoft-Teams

 

 

 

 

 

 

 

1 Comment

Filed under Best Practice, Cloud, Collaboration, Microsoft

Microsoft Search – isn’t that just Bing?

Microsoft Search was just announced (Ignite 2018, last week in September). To be honest, when I saw the announcement, my reaction with “Hmmph. So what”
Since when I have been reflecting on it quite a bit; and showing Microsoft Search to various people. I’m now shifted from “Hmmph” to “Gosh! Hmmm, that could really work”. Everyone I have shown it to has said it’s good – even my technosceptical wife.

Ordinary users rarely think to go to their intranet to look for things – they jump straight to a search engine – almost always Google

Microsoft Search, like so many good ideas, is a simple concept. Ordinary users rarely think to go to their intranet to look for things – they jump straight to a search engine – almost always Google. Diverging, for a moment, there is a well-worn process that architects etc. use when deciding where to lay paths and pavements; they wait a few months and then put them where the grass has been flattened by heavy footfall. Microsoft are doing the same – instead of plaintively pleading with people to go to where Microsoft would like them to be, they are putting the things tools where the people are already going – it seems that Microsoft have learned, at last, that they can’t dictate behaviour to end users. With Microsoft Search, they are putting corporate search where the users are, rather than trying to force users to the intranet, where the company search has traditionally lived. Microsoft Search cleverly returns results from across Office 365 as part of the ordinary search engine results. The caveat is that the search engine has to be Bing, not Google (more on that later).

Microsoft are putting corporate search where the users are, rather than trying to force users to the intranet

MS_Search
For the user, it’s as simple as opening a browser (probably Chrome or Edge) and typing their search into the search box or address bar. At the top of the results they get are items from across their Office 365, including SharePoint, OneDrive, Yammer (and soon to include Teams, Stream etc.). There are even some fancy recommendations, branding and the ability to limit the search to files, sites or conversations. The only thing the user really needs to do is ensure that they have logged in to the browser with their work credentials, and presumably this is something which can be automated by canny IT departments.

For the IT department, there’s a little bit to do but is not too onerous. They need to set up Microsoft Search from the admin portal, which is available via the Office 365 admin centre. From here it’s possible to apply a branded logo and colour, as well as provide some search suggestions to get people used to the concept. There other neat features here, including the ability to build out question-and-answer sets (which is almost certainly using Azure QnA Maker), define bookmarks for recommended links (and import SharePoint best bets where this concept originates), alongside the expected management capabilities.
It is also likely that IT will want to push out Bing as the default search engine using group policy. There’s probably a piece of work to do to reassure users and management that this is not exposing corporate information to the Internet.

But… Bing!
There’s bound to be a few raised eyebrows at the use of Bing. However, the choice of Bing versus Google is a bit like being forced to choose between a Maserati and Ferrari; they’re both really rather good, even if you’d rather have the Ferrari.
Let’s think about this for a moment. Microsoft have lost the battle against Google on the personal desktop, even though Bing is a perfectly adequate engine. But in the corporate space they might just win it with this move; there’s no real downside to this choice of search engine and the ability to present corporate content is a huge win. Organisations actively need their users to be accessing curated and governed company knowledge rather than finding out things from the Internet.  They don’t even have to force users to use Edge if they don’t want to (though it has become an excellent browser over the last year); every decent browser lets you define the default search engine.

Benefits

  • Users will love it, so they will use it. It’s quick, doesn’t require any training and shows user relevant results that they would otherwise miss. Plus it takes zero effort or knowhow.
  • It increases the chance of users finding what they need, while improving compliance and governance.
  • It provides richer results than just an Internet search, including finding people and conversations, not just documents; this can include specific bookmarked content and frequently asked questions. It’s probably better than their current intranet search, in fact.

What of the intranet?

If we place this release alongside the rapid rise of Microsoft Teams (allegedly the fastest adopted application Microsoft has ever built) and the rapid shift to mobile apps, and it does beg the question of the role of an intranet in general and the value of the intranet home page in particular ( especially as it relates to SharePoint).
A decent intranet attempts to pack search, news, applications and interactive content onto the homepage, while team and departmental collaboration sites lurk within the structure. However, modern SharePoint Online sites seamlessly push news content to the SharePoint mobile app, ready to be consumed by users on their Android or Apple phone. The recently promised option to add custom applications into Microsoft Teams (which is equally happy on the desktop or the mobile) means that the majority of users may never need to touch the browser-based intranet, other than via the mobile application. This means that they will never see the homepage.
It may take a few years, but is now easy to imagine a future where the current concepts of an intranet are genuinely thing of the past; users will simply have no need to go to a ‘stuffy intranet home page’ for the vast majority of activity, they will be using Teams for collaboration, interaction and business process (perhaps supported by custom Power Apps) and consuming content via the SharePoint app (until it gets called something else). The role of the SharePoint partner or internal developer will change it again, with even more emphasis on strong information architecture to support intelligent content and coordinate the rich ecosystem of content, communication, collaboration, business process and people. Advanced content management will underpin everything, but the user experience will happen somewhere else entirely.
You can find out more about Microsoft Search here and on the site Bing or set it up via your  Admin Portal if you are already in Office 365 organisation.

Leave a comment

Filed under Cloud, Content management, Innovation, Microsoft, Office 365, Search, UI and UX