Hands-On on Thomy Gölles

How to present at online meetings and events like an Ignite Superstar

Mon, 23 Nov 2020 00:17:43 +0000

Introduction

Most of you probably saw some images in a blog post or tuned in for some sessions at Ignite a couple of weeks ago. There was a clear difference in production value compared to what we all saw at Build in May of this year and the Microsoft superstars had made a big step in terms of presenting to a virtual audience.

If you look at keynotes at those big events with a big audience in a conference room you are pretty sure that you will never be able to recreate this setup at home. With everything being virtual at the moment we can challenge that assumption. We start by a simple question: Can you turn your next Teams meeting in an Ignite-like keynote presentation?

Microsoft365DSC remote name could not be resolved lyncdiscover

Mon, 11 May 2020 15:29:37 +0000

A couple of days ago I stumbled upon a LinkedIn post/article by Nik Charlebois about the Microsoft365DSC project. The first sentence on Github already sold the idea to me “This module allows organizations to automate the deployment, configuration, and monitoring of Microsoft 365 Tenants via PowerShell Desired State Configuration.”

After starting to playing with it a little I came across a nasty error that took me some time to resolve. To prevent others from also losing valuable time I thought it might be a good idea to document the steps.

Microsoft Teams Automation - Create Team from Webhook

Fri, 03 Nov 2017 17:54:49 +0000

Today Microsoft released the Microsoft Teams Powershell Cmdlets module (https://www.powershellgallery.com/packages/MicrosoftTeams/0.9.0). This allows you to use PowerShell as the first basic API for Teams. Bill Bliss (@bill_bliss) from the Teams Team (still awkward wording) told us this week on Monday in a session at Microsoft Vienna that they will push the PowerShell Cmdlets in the coming weeks and the Graph API will follow. To be honest didn’t believe that they would be that fast in releasing the bits but I’m more than happy now. To take this a little further I created an Azure Automation Runbook for the CreateTeams Cmdlet in my Azure Tenant. The Runbook itself can be triggered by a webhook. With that in hand, you basically can create a bot or a Teams app to create or update your Teams based on the cmdlets Microsoft released. The Runbook I created uses the basic steps for reading input from the webhook based on this blog post: https://blogs.technet.microsoft.com/stefan_stranger/2017/03/18/azure-automation-runbook-webhook-lesson-learned/``` [CmdletBinding()] Param ([object]$WebhookData) #this parameter name needs to be called WebHookData otherwise the webhook does not work as expected. $VerbosePreference = ‘continue’

The O365 app launcher - your digital workplace/intranet start menu

Fri, 16 Dec 2016 22:00:51 +0000

The last couple of months Microsoft added some major updates to the top left navigation menu in Office 365, the app launcher. You are now able to add custom tiles with a title and a custom image to the app launcher. Furthermore, if you are already on SharePoint 2016 and use it in a hybrid configuration connected to Office 365 your app launchers can be combined. That allows you to serve the same tiles in the cloud and on premises. So far so good, but that’s only the introduction part. If you plan to use SharePoint Online for different workloads you may end up designing an information architecture that uses more than just one site collection. If you create a portal with this architecture a consistent navigation is helpful to guide your users, just to make sure they are not lost on the different site collection pages. As the majority of people started their SharePoint endeavour before they went to the cloud, some of them already have some experience in customising SharePoint and especially the navigation part. Their users also have at least some experience in just browsing different web pages and that’s why you end up discussing how you can integrate a “global navigation” somewhere in the red area of the screenshot below. If you knew the trick you even could create such navigation elements in SharePoint 2013 just by using a special PowerShell command. Of course, we used this approach in our projects what in some cases looked like this: You can build such navigations by customising your masterpage or injecting some JavaScript into the right places. As a data source, you can use a simple XML or JSON file or if you want your SharePoint admins to edit it in an easy way you use the managed metadata service as a source. Office 365 on the other hand, has some other plans with this first part of your page, to be accurate we are talking now about the red part of the screenshot below: If you just look at it and remember the tools you built for on premises, your first clue is probably to put your global navigation here. Again you can achieve this by changing the masterpage or some JavaScript. But in O365 the trouble has started just now … First of all this top bar was changed, I think at least three times in 2015. So your custom navigation maybe had to be changed multiple times and guess what, nobody warned you about that. Second of all, if you start with let’s say SharePoint online as the first workload in O365 chances are your users will also use different other services provided by their license. How’s the top bar gonna look like in OneDrive or Delve if you customised only the SharePoint masterpage? Plain simple you are unable to provide a true global navigation across all the different O365 services by just changing the SharePoint masterpage. That’s why Microsoft provides the app launcher. To be fair, even the app launcher isn’t working in exact same terms across all the different parts of O365, but for sure sooner or later it will be. So to enable a true integration of your services in O365 you should think of an approach like this: With this approach, you have to think of your different portals like any other service in O365. Your end users will love the consistent integration of custom services in the native Microsoft environment. If a new important service is ready just add a tile to the app launcher. Best part, if Microsoft adds new services they will also end up in the app launcher.

Cross Site Publishing and Variations: hands-on experience

Mon, 24 Jun 2013 21:53:36 +0000

Over the last months we had the chance to get our hands dirty in the new 2013 way. In this post I want to share some of the decisions we made by using the content by search webpart and the variations feature heavily. Introduction Late last year a customer asked us to implement a partner portal. He thought about a different publisher area where he is able to manage the content in German and a portal for each language group available. He wanted the upload use case as simple as possible to allow his co-workers to update the information without any further assistance. Also he requested to “somehow” tag the content for all other languages (FR, EN, IT, RU, CN) in German because they are not able to support all languages in the upload team. They also wanted to display the files in a “nice” way and the standard SharePoint list wasn’t included in their definition of nice. All user data (username, passwords) already existed from the up and running partner portal in use so we had to build a solution integrating all of this users in SharePoint. Also we had to guarantee that people from a defined language group can only access content of their configured language. How we did it Actually we already thought about XSP (Cross Site Publishing) and variations in our very first meeting. At this time we also thought that managed metadata navigation will be a good way to handle all the navigation settings in the portal, but … yeah that was plain wrong. Remember: you are not able to configure security trimmed links via managed metadata navigation. Everybody with access to the selected web will see all configured navigation links. For me that was a huge surprise. I had in mind that SharePoint *always* handles the navigation in the security context for the current user. With managed navigation that is not the case. So if you want to put some security in your navigation, you can’t use this new set of features. The XSP on the other hand worked like charm. We set up a document library as a catalogue for the content by search webpart. We used a term store to tag all the documents with the right category. To allow a real fast upload and publish process we mixed the metadata with a folder structure and worked with the default column values for the different folders. This enables the publisher to open that special library with the explorer view and allows a very fast upload with integrated tagging. For the ease of use we just implemented one document library with root folders for each language. From there on every language has a different subset of all available elements. The German portal hast the most content and every other language has just a subset of the German folder structure. With this folder structure the author only has to copy the documents to the right folder without any further configuration. Furthermore the author never has to actually update something in the user’s area. The only reason to browse the documents is to see if search already picked up the changes. Next step was to configure the variation root and the needed languages. In a first phase we built the German portal, so the variations generated a sub web with /de-de as our start url. In this web we created different web part pages for every content category. On every webpart page we configured a content by search webpart filtering on the specific content category. By using a custom display template we were able to show some specific information and a thumbnail for each element. That was some kind of tricky because we had to display documents and images as well with the same display template. If you dig deep into a search results node you recognize that the url to your element is different for documents and images, so you can’t build your href the same way. SharePoint always gives you the link to the display form for images in a document library if you use the Path property. You have to use a special property (DefaultEncodingURL) to get the full href to the specific picture. Security In terms of security we used SharePoint groups heavily. Every language has about 10 types of different user groups with different access rights. Both, the authoring web and the variation webs are security aware. All users are stored in a SQL database that is configured as a FBA membership provider source in SharePoint. Within the FBA administration every user can be configured for a different role in the portal. Adding a new language The task of adding a new language to the portal is accomplished by a mix of hands on configuration and some powershell scripts. All content is uploaded to an instance of the defined folder structure and tagged properly. The variations feature creates the new subweb with the target language. The SharePoint standard user interface supports the language by installing the right language pack. All custom menu entries at the navigation configuration have to be updated with the translated terms. All webpart headings are set via a powershell script. We used some of Gary Lapointe’s powershell magic to update webpart properties. Conclusion The out of the box features of cross site publishing and variations are really a huge step forward for the product. Yes they are built with a little focus on web publishing and anonymous access where also managed metadata navigation integrates well. But I hope this post gives you an idea how this features can also be used in a security aware intranet solution. References: Without the help of this blogs and articles we never could have accomplished the given task! Thx!