Published on March 15 in the Office 365 Admin Center, there are several changes coming to Microsoft Whiteboard you should be aware of, especially if you have Surface Hub in your organization:
In Office 365 services, organizations that have “Whiteboard” enabled will see “Microsoft Whiteboard” that will be automatically enabled. No action required by admins.
Office 365 organizations that are located in Europe will have their data content move to their regional data centers rather than the US data centers that were used so far. No action required by admins.
For Surface Hubs, the “Microsoft Whiteboard 2016” app that’s installed by default in the Windows 10 Team OS will be automatically upgraded to the new “Microsoft Whiteboard” app by May 21, 2019. The legacy “Microsoft Whiteboard 2016” collaboration feature will stop working in early June 2019 and the app is expected to stop functioning and will no longer be supported starting June 7, 2019. If you disabled automatic Store updates on your Surface Hub’s Store app, make sure you re-enable them to get these updates.
I was looking for an ‘easy’ way to push the Microsoft Teams app to devices using Intune.
Since the ‘Windows S’ Teams app is no longer available, the options were to either create a ‘Line of Business’ app in Intune or use Graph API. Both valid options, but – why?
Looking at the documentation to install Microsoft Teams using MSI, you can use System Center Configuration Manager, Group Policy or any third-party distribution mechanisms for broad deployment. As Intune falls into the latter, if you’re on a modern-managed environment – I prepared a script for that purpose.
The script will do the following:
Download the x64 MSI installer directly from Microsoft. (You can use the x86 MSI as well if you need)
Extract the installer to a folder on the client machine and run the installation quietly with the least possible privileges .
Based on the default behavior of the installer, whenever a user signs into a new Windows User Profile, the installer will be launched and a copy of the Teams application will be installed in that user’s appdata folder. If a user already has the Teams app installed in the appdata folder, the MSI installer will skip the process for that user. So you can rest assure that the client doesn’t reinstall itself every time a user signs in.
Save the above script as a .ps1 file and upload in to Intune PowerShell:
In the Intune Devices Management Portal (https://aka.ms/apmgmt), go to Device configuration – PowerShell scripts and click to Add a new PowerShell script.
Provide a name and the location of the .ps1 file you created:
Click to configure settings, and make sure that both ‘Run this script using the logged on credentials’ and ‘Enforce script signature check’ are set to ‘No’:
Click ‘OK’ and ‘Create’ and assign the scripts to the device groups you desire.
Right after syncing, you’ll see the following events on your machine:
These will confirm that the installation was successful and users will be signed in to Teams automatically on the next log on.
Originally written for the Microsoft Teams for Surface Hub (Preview) app, this article is now updated to support the GA version of the app. Images may still contain ‘Preview’.
In this post, I’m going to cover the steps required to push the Microsoft Teams for Surface Hub app to Surface Hubs and configure its options using Intune.
To push the app to the Surface Hub you’ll have to you’ll have to configure Intune and the Microsoft Store for Business to push apps to the Surface Hub. Follow this post to configure both if you haven’t done it yet.
Remember – you must acquire the offlinelicense version of the Microsoft Teams app (No purchase required) to be able to push it using Intune:
After syncing the store with Intune, you’ll see the app in the Apps list:
Next, configure the Microsoft Teams app CSP settings in Intune.
Create a new Device configuration profile in Intune. Set the Platform to Windows 10 and later, and the Profile type to Custom:
There are two dedicated CSPs we’re using to configure the app on the Surface Hub. Both must be present for the app to work:
./Vendor/MSFT/SurfaceHub/Properties/SurfaceHubMeetingMode is the CSP that replaces the .ppkg files you’ll be using if you’re manually installing the app. it comes with the values of 0, 1 or 2 and would act as follows:
0 – Skype for Business is the preferred app on the Surface Hub’s Start Screen, however you can still join Microsoft Teams meetings.
1 – Microsoft Teams is the preferred app on the Surface Hub’s Start Screen, however you can still join Skype for Business meetings.
2 – Microsoft Teams is the exclusive app on the Surface Hub’s Start screen and Skype for Business is disabled.
The Data type for this setting is Integer and you can choose any value from the above as illustrated in the following image:
./Vendor/MSFT/SurfaceHub/Properties/VtcAppPackageId is the CSP representing the app ID that’s replacing Skype for Business; Microsoft Teams. The value for this CSP is always Microsoft.MicrosoftTeamsforSurfaceHub_8wekyb3d8bbwe!Teams
The Data type for this CSP is String. Copy and paste the value from the line above as illustrated in the following image:
To assign the policies (App deployment and Device configuration) to the Surface Hubs, create a security group with the Surface Hubs deviceaccounts:
Go back to the Microsoft Teams for Surface (Preview) app in the Apps list and click ‘Assignments’. Assign the app to the Security Group you created with the following settings:
Assignment type must be Required.
On the Select groups to include list, choose the group you created earlier and set the license type to User licensing:
Click ok and save the configuration.
Next, for the Device configuration profile, assign it to the Security Group you created:
Intune will push the and settings immediately. You may need to restart the Surface Hub to complete the process.
Whether you have five, fifty or five hundred Surface Hubs, managing and delivering updates to your Surface Hubs is as important as servicing your other Microsoft products.
Let’s see how to get it done right:
What are our options?
No matter how you manage your Surface Hubs, you have two update options:
WSUS– In which you can utilize an on-premises WSUS infrastructure to approve and deliver updates to your Hubs.
Windows Update for Business – Also known as WUfB or just “Windows Update”, where updates are being downloaded directly from Microsoft. Based on you organization’s policy, you might choose to deliver only some updates and defer\delay other updates to your Windows devices.
There are 3 types of updates offered by WUfB: (Source)
Feature Updates: previously referred to as upgrades, Feature Updates contain not only security and quality revisions, but also significant feature additions and changes; they are released semi-annually.
Quality Updates: these are traditional operating system updates, typically released the second Tuesday of each month (though they can be released at any time). These include security, critical, and driver updates. Windows Update for Business also treats non-Windows updates (such as those for Microsoft Office or Visual Studio) as Quality Updates. These non-Windows Updates are known as Microsoft Updates and devices can be optionally configured to receive such updates along with their Windows Updates.
Non-deferrable updates: Currently, antimalware and antispyware Definition Updates from Windows Update cannot be deferred.
Is the Hub different?
Surface Hub is running a special version of Windows OS called “Windows 10 Team Edition”. It’s a locked-down, secured, Surface Hub-specific version of Windows 10. It is being serviced with the entire Windows 10 branch, and therefore will be getting the regular security updates and monthly updates just like any other Windows 10 OS. This means that whenever we release an update to Windows 10, even if the KB states that “This update introduces no changes to Surface Hub” or if the update doesn’t mention Surface Hub, it would still apply to the Surface Hub as the Windows 10 Team Edition OS is a Windows 10 OS. Since Windows 10 Team Edition is designed to only work on Surface Hub, it has a few apps and features embedded into it that would require special attention when we release new features to Windows 10. This is why we moved to a services-approach for Surface Hub, releasing updates as they become available instead of bundling them into larger software updates. This enables us to be more agile and ensure we are providing the best experience to our customers. It helps us deliver tailored, stable updates based on your feedback, that are tested for delivering the required Surface Hub features – all bundled as quality updates. This is also why we release Surface Hub-Specific updates on the week following ‘Patch Tuesday’ – We’re assessing and confirming the standard Windows updates released on the second Tuesday of every month, and releasing fixes and other Surface Hub-related updates on the following Tuesday, the third Tuesday of every month.
How to prepare?
Well, there isn’t really a “One size fits all” solution here. Some organizations like to have time to test updates, some don’t. Some would have Surface Hubs on the Windows Insider program, some are only interested in the more stable updates. If your organization is large enough, my recommendation would be:
Insider – Have at least one Surface Hub on the Windows Insider program. We’re trying features all the time and your feedback is priceless. Make sure you do submit your feedback if you like something, and make sure your voice is heard if we’re missing something or removed your favorite feature. As always with Insider, some builds could be glitchy and unstable, and not all features will make it to the production builds. Note that Insider Surface Hubs have a message on the top left corner saying they’re on an Insider build, and that the only way to revert to a production build is to reset your device.
Test – Have a few Surface Hubs on immediate release, These devices can be used to test the stability and new features of Surface Hub as updates are delivered. This is the default configuration of Surface Hub, so should be fairly easy to manage.
Production – For all the rest of your Surface Hubs, measure how long it takes you to test and assess the builds and updates we’re shipping and then defer the updates based on this evaluation. As we’re applying Surface Hub updates on the week following Patch Tuesday, I recommend allowing at least 14 days before you apply the updates to your production devices. This means: That if, for example, we release the Windows 10 updates on Tuesday June 12, we will be releasing Surface Hub specific updates (if any) on Tuesday June 19. This will give you enough time to test the builds and updates and also enough time to apply the updates after potential Surface Hub updates. By July 3rd, you’ll be running the tested patches across all your Surface Hubs.
How to Control this?
Intune to the rescue! If you only have 2 or 3 Surface Hubs you want to connect to the Insiders ring, you might be better off adding them manually. Remember that now with the Surface Hub Recovery Tool, it’s much easier to recover your devices’ hard drives is something went wrong. For your test Surface Hubs – you don’t have to apply any update ring. They’re programmed to automatically install all Windows updates during the daily maintenance window, and will do so by default. For you production Surface Hubs – Create a new update ring (or rings, if you want to divide by region, department, screen size, etc.) in Intune (Software Updates -> Windows 10 Update Rings) and follow these guide lines:
Use the Semi Annual Channel to update Surface Hub. This is the most frequent update channel, and will of course allow for all other Windows Updates to be delivered.
Allow Microsoft Product Updates and allow Windows Drivers Updates.
For “Automatic Update Behavior”, leave the setting on “Auto install at maintenance time”. You can control this setting with a Device Configuration profile in Intune.
You can Skip the “Restart Checks”, Surface Hub will take care of that during the daily maintenance window.
Defer the Quality and Feature updates for up to 30 days. You can always pause the ring if you need more time.
Ignore the “Delivery optimization download mode” setting. Surface Hub will not honor this part of the policy as it can’t be changed anyway.
Assign this policy to your Surface Hubs and monitor it using “Device Status”.
There are quite a few considerations (and benefits!) when introducing Surface Hub to your organization. It introduces great new collaboration abilities, but also challenging the way you configure, manage and monitor it.
This gets even more challenging when working in a Multi-Domain or Mutli-Forest environment, where allowing users from different domains and forests to book resources on other domains.Let’s see if we can break that down in a way that makes sense:
(Going back to Windows Server 101, let’s recap what Active Directory Forest and Domains are…)
Domains are container objects; They are a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains.
Domain trees are collections of domains that are grouped together in hierarchical structures; When you add a domain to a tree, it becomes a child of the tree root domain. The domain to which a child domain is attached is called the parent domain.
A forest is a complete instance of Active Directory; A forest acts is a container that houses all the domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects. By default, information in Active Directory is shared only within the forest.
So basically, you can have multiple forests that have multiple domains in them. By default, a domain provides authentication and authorization services for all its accounts, in order to facilitate logons and single sign-on access control to shared resources within the boundaries of the domain.
Forests can be used to segregate domain containers into one or more unique DNS namespace hierarchies known as domain trees. Because the forest is a security boundary, each forest does not trust or allow access from any other forest by default.
If your environment has multiple forests such as a User forest and a Resource forest, you might want to check this article in the Surface Hub Admin Guide.
Nevermind the setup, how do we get collaboration working right?!
Let’s try to answer some of the common questions that we normally see:
– How would you handle booking hubs? If we tied all the hubs to one parent domain, would TNEF & and proper federation allow for any of the sub domains to book hubs?
First, allow your Surface Hubs to receive external meeting invites. This will allow users outside your Exchange Organization to invite the Hubs’ room mailboxes.
To enable that, run the following command against your Hubs:
TNEF configuration is not required for Surface Hub when sending meeting invites from remote domains. The Skype for Business client on the Hub can read the meeting url in the invite, and does not require the “winmail.dat” attachment in the invite header. If you’re using Skype Room Systems as well as Surface Hub – TNEF is required for SRS and can be configured using these instructions.
Federation is required and must be configured between both organizations for the Hub to join the meeting. Check with your Skype for Business admin that federation is enabled and add the remote domains if required:
New-CsAllowedDomain -Identity "fabrikam.com"
To further simplify the process, create a Mail Contact for the Hub in every remote organization so that users can easily find it and send it meeting invites:
Diagram 1 above explains what happens when Jess from the Fabrikam domain wants to invite “Surface Hub 20” on the Contoso domain:
Jess will use the Address Book in the Fabrikam domain to find the Mail contact for Surface Hub 20 in the Contoso Domain.
The invite will be sent to SurHub20@contoso.com
A response will be sent directly to Jess based on the resource availability.
This is common in multiple-domain environments where admins can create mail contacts for users in other domains.
Diagram 2 above explains what happens when Jess from Fabrikam invites Alan from Contoso to a meeting, which Alan then forwards to “Surface Hub 20” in his organization:
Jess sends a Skype Meeting invite to Alan.
Alan forwards the meeting invite to “Surface Hub 20”.
“Surface Hub 20” will accept or decline the meeting based on availability.
– Will users from any Office 365 tenant be able to login to “my files” on OneDrive?
Yes. Especially if your organization is using Office 365 and your environment is optimized for Office 365.
Any user can log on to their files on Office 365 once they authenticate, subject to their organization’s policies.
– Will users from any tenant\domain be able to Miracast?
Yes, Miracast does not require user authentication in order to project your screen to the Hub. Anyone with a Windows 10 device or a compatible device can project to the Hub.
For more information check the Surface Hub Admin Guide here.
Surface Hub takes advantage of all the automatic configuration options Microsoft’s Productivity tools has to offer; it will use Exchange’s autodiscover to find the Room Mailbox’s account and policies, and will use Skype for Business’ Lyncdiscover to locate the Conference Room’s registrar.
Due to the nature of Surface Hub’s OS (Windows 10 Team Edition), and due to the fact that it’s a locked-down, secured, communal device, it will not show you any popups during the step-by-step configuration (OOBE) or later when it attempts to connect to services and servers. This makes the environment preparation task even more critical: When installing them, Surface Hubs can be configured individually by the installer if they have the required information, or using a PPKG file for mass deployments. In any case, having all the required information is crucial – as the installation will not complete if it hits an issue along the way.
One of the most common issues with Surface Hub installation and Skype for Business is the Trusted Domain List.
What is the Trusted Domain List and how to get it right?
The Trusted Domain List, also referred to as the “TrustModelData” is a List of the trusted domains that don’t match the prefix of the your SIP domain.
When a user (or a device, in this case) connects to the Skype for Business server, the client validates the connections against a list of trusted servers.
Who are the trusted servers?
The users’ SIP URI domain
Any server that the client connected to in the past, and that was added to the Trusted Domain List (More on this below)
The domain of the server that the client last connected to
Let’s break these down:
Scenario 1 is pretty straight forward; if the users’ SIP URI domain and the servers’ domain are the same, there’s an automated trust and the client will sign in immediately.
User’s SIP URI
Scenario 2 is where the users’ SIP URI is different than the servers’ domain (due to internal naming convention – for example: domain.local, or due to users\resource forests, etc.)
User’s SIP URI
In this case, the Trusted Domain List can be prepopulated by the admin via GPO or manually configuring Registry keys, and also by the user:
Every time the client connects to a new server – an untrusted server – the user will receive a prompt saying “Skype for Business cannot verify that the server is trusted for your sign-in address. Sign in Anyway?”
Once the user clicks Connect, the server is added temporarily (See Scenario 3) to the Trusted Domain List. If the user will go ahead and check the “Always trust this server” box, the server will be added to the Trusted Domain List and the warning will never appear again.
Scenario 3 is what’s happening when the user connects to an untrusted server and acknowledges the ‘Sign in Anyway?’ popup. The server we’re connected to is saved in the registry and will remain there until the user connects to a new server. As long as the server is there, the user will not be prompted to trust the server:
For most workstations, the Trusted Domain List will be pushed via using Skype for Business Server 2015 in-band provisioning, but it can also be pushed using Registry keys or GPO.
What does this have to do with Surface Hub?
Surface Hub will not prompt you to ‘trust a server’ if its not on the Trusted Domain List. Instead, you’ll have to make sure that all possible domain names are represented in Surface Hub. Otherwise, the Skype for Business client will not connect:
However, other features, like Emailing the whiteboard, will work, as Exchange doesn’t require a Trusted Domain List:
The Trusted Domain List on the Surface Hub can be edited in one of the following ways:
Add the domain name in the “Configure domain name” window , under Settings -> Surface Hub -> Calling and Audio
Using the Windows Configuration Designer, perpare a PPKG file that contains the domain name under RuntimeSettings/WindowsTeamSettings/SkypeForBusiness/DomainName
Using Microsoft Intune, crate a new custom configuration policy for Windows 10 Desktop and add the following OMA URI:
Had an interesting request lately, where a company wanted to control how users join meetings when they click the “Join” on their Skype for Business clients’ calendar tab or when they join Skype for Business meetings from Outlook.
In the client’s options, we have the ability to choose what happens when we join meetings; We can join immediately using the Skype for Business client or choose from four different phone numbers, all of which must be populated in our contact card, and can be seen under Tools -> Options -> Phones.
If your AD is configured right, you should have your Work phone (ideally your Skype for Business line URI), your Mobile phone, your Home phone and maybe even an additional ‘other’ phone.
You can also manually add phone numbers if they’re not automatically updated from AD.
Now if you scroll down the tabs to “Skype Meetings”, this is where all the fun begins:
In the tab above you can choose any of the numbers you have in the ‘Phones’ tab and get to choose whether you’d like to be prompted at the beginning of each meeting which device you’d like to use, or just go with what you chose.
How do you control it?
Like most things, the Registry.
You can make changes to the user’s preferences but not grey-out the options. If the users want to bypass the setting they can, but they’ll be defaulted to your setting at logon.
First, decide if you want the user to be prompted with each call. If yes, we need to tick the “Before I join meetings, ask me which audio device I want to use”.
The registry setting fro this checkbox is located at
If it’s set to 1 – it means the box is ticked and the user will be prompted to choose which device they’d like to join the meeting from.
If it’s set to 0 – it means the box is unticked, and the user will automatically join via the configured device.
Choosing a device is the next funny setting:
Same registry location as above, look for the following key:
The setting of the last binary bit is as follows, as reflected in the users’ “Phones” tab:
0 – Do not join Audio.
1 – The Skype for Business client.
2 – Work Phone (If different from your Skype for Business line uri).
3 – Mobile.
4 – Home.
5 – Other.
If one of the above is not configured or missing, the client will default to “Do not join Audio”.
For example, if I want to set my users to join from their mobile phones without being prompted, I’ll set the AllowOverridingDeviceAtJoinTime registry key to 0 and the JoinAudioConferenceFrom key to 3.
I had a very annoying issue lately when an installation of a new gateway resolved in some calls (specifically to US numbers) dropped by the Skype for Business mediation server saying “A call to a PSTN number failed due to non availability of gateways.”
The cause, according to the mediation server, was that “All gateways available for this call are marked as down“, and the resolution, surprisingly, was to “Verify that these gateways are up and can respond to calls.”
It seemed funny, because all other calls were successful, I have not exhausted the available PRI channels I had, the gateway didn’t seem to lose connectivity for a split second and SIP options are accepted and replied to on both ends.
Looking further at the Lync Monitoring Reports, I noticed the following:
Reported by Client 12000; reason=”Routes available for this request but no available gateway at this point”
Reported by Server 12000; reason=”Routes available for this request but no available gateway at this point”
I went to the gateway (AudioCodes M1000B) for answers and the logs were showing something very weird;
Every call starts with the same flow:
The mediation server sends a SIP Invite that will normally be answered immediately by the gateway with a “100 Trying”. This, for me, will close the deal on the “Gateway no responding” – this is a great response if you ask me.
The next phase would be the gateway immediately sending a “PSTN Place call” to the PSTN, hopefully receiving a “Proceeding” instantly from the PSTN, meaning so far we’re fully communicating. So for the time being I’m not really buying what the Lync mediation server is selling.
Looking further at the logs, I see the following strange behaviour:
As I’m still waiting for the PSTN to connect the call (this would normally be a “PSTN Call Alerting” message), I see that the mediation server decided to abandon ship!
This is what I see in the logs:
Within 10 seconds after initiating the call, the mediation server will send a “Cancel” request to the gateway and will terminate the call:
Clearly, the gateway is available and responding, but the mediation server is somewhat impatient.
Doing a bit of digging around, it appears there’s a setting for this.
The Lync mediation server is expecting a “SIP 180 Ringing” within 10 seconds of initiating the call. Failing to provide that (183 “Session in Progress” can be pushed here but that won’t benefit you if you’re still waiting for that ring…) will cause the mediation server to decide that the call didn’t respond and to mark the gateway as unavailable. A little too harsh? In my opinion yes. This will generate errors (2 per failed call) on your Lync servers and is actually a Lync self-inflicted error.
To work around this issue you can go to: <Lync or Skype for Business installation folder\Server\Core and look for a file called “OutboundRouting.exe.config“.
When you open that file, the first configuration line is: <add key=”FailOverTimeout” value=”10000″/>
This actually determines how long should a call wait for the gateway until it declares it “Offline”. the value is in milliseconds, meaning the default setting is 10 seconds.
This will impact your environment if you have two or more gateways, and it means that it’ll take the mediation servers more than 10 seconds to declare that gateway as offline if it actually fails.
For me to workaround that issue I extended the wait time to 20 seconds, restarted the front-end and mediation services, and all of a sudden no call was dropped.
It appears it took the carrier approx. 12 seconds to generate the “PSTN Call Alerting” command to the gateway. For some reason, only calls to the US (and only with this specific carrier) were affected by this issue.
Now, I can see all my calls working perfectly and the errors have disappeared from the serves too.