A few days ago, Matt Ballantine wrote about Enterprise Social Media and the need to focus on building an audience:
Internal communications people can fall into the trap of believing that what they produce is content rather than advertising. Internal communications appears to be the only form of direct marketing to which there is no legal right to opt out.
The challenge then with Enterprise Social Networks, especially when they are treated as an internal media channel, is that if all you are pushing out is advertising (and yes, the latest interview with the CEO about the next 5 year strategy is advertising) you are trying to build an audience on marketing alone.
So, cue Yammer, Microsoft’s Enterprise Social Networking product, purchased a few years ago and slowly being integrated into Office 365…
As I wrote back in July, Yammer comes in two flavours:
- Yammer Basic is a bit like the wild west – users sign up with their corporate email accounts and a network is formed, using company resources, but over which the company has no control.
- Yammer Enterprise is a paid product, included in certain Office 365 Enterprise subscriptions, which provides a level of administrative control.
But, here’s the gotcha – once you activate Yammer on your Office 365 subscription, a Yammer tile will appear on the Office 365 App Launcher and you have no way to turn it off.
I was recently working with a customer who had activated Yammer on their domains (to shut down the anarchy of Yammer Basic) but who wasn’t ready to start using the product yet (going back to Matt’s point about building an audience – i.e. launching the platform in a controlled manner, with appropriate business sponsorship and support).
Disabling logon to Yammer
With a Yammer tile in Office 365 but no way to turn it off, I was left looking at options for restricting access to Yammer:
- Use block lists to prevent users from logging on. That doesn’t scale and would be an administrative nightmare, so it’s not really a credible option.
- Disable Yammer in ADFS using a claims transformation rule (more information on TechNet). This would have been a nice idea except that Yammer SSO is deprecated since support for Office 365 authentication was introduced (it’s still supported, but not being developed). Denying access to Yammer on the Office 365 Identity Platform relying party trust meant that I also denied access to other Office 365 services!
- Use PowerShell to modify user licences except that doesn’t work – changes to the YAMMER_ENTERPRISE plan do not have any effect.
- Use Yammer’s logical firewall to block access based on IP address (thanks to Steve Rush for the suggestion). This is a bit crude but it works – just make sure there is a range for which access is allowed, so you can still get in and administer the network when you are ready to start using it!
In addition to the challenges created by the unified contacts store, my recent Office 365 migration project saw some issues where a user’s Lync/Skype for Business client failed to pick up a change in Exchange Web Services (EWS) as part of the move to Skype for Business Online.
The reason for this is unclear but I’m not the only one who’s experienced it – Richard Brynteson describes exactly the same scenario where, after a migration from an on-premises Exchange mailbox to Exchange Online, the Lync 2013 client is unable to connect to the Exchange server and pull conversation history and meeting information.
If we looked at the configuration information for the Lync client (by
Ctrl+right clicking on the Lync taskbar icon), we could see that the client was not autodiscovering the move to Exchange Online and still showed on-premises Exchange details, instead of a blank EWS Internal URL and an entry of https://outlook.office365.com/EWS/Exchange.asmx/WSSecurity for the EWS External URL.
One suggestion given to me to force a new autodiscovery search was to wipe the user’s cached client information (in %appdata%\Local\Microsoft\Office\15.0\Lync\firstname.lastname@example.org). That sounded a little destructive but Richard’s post suggests removing a single registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\email@example.com\Autodiscovery.
Even better though is the solution from a comment on Richard’s blog post, from “Chad”:
We’ve resolved this by having users sign out of Lync and then choose “Delete my sign-in info”, then just sign back in and their Lync client now connects to 365. We provide this as post-migration steps to users once we move their mailboxes to 365. Hope that helps and is typically easier than deleting [registry] entries.
That’s a much more user-friendly fix (which worked for me) – and it’s one to add to the project FAQ list.
In a recent Office 365 project, I came across an issue where, if we migrated a user’s Exchange 2013 mailbox to Exchange Online before we migrated their Lync 2013 user to Skype for Business Online, the
Move-CsUser cmdlet generated an error:
Move-CsUser: Exception of type ‘Microsoft.Rtc.Management.AD.Helpers.RollbackException’ was thrown
This is described in Camille de Bay’s blog post and appears to be related to the Unified Contact Store, which is enabled by default with Lync 2013 and Exchange 2013. There appear to be two options:
- Migrate Lync before Exchange
- Use the
-force switch with the
Move-CsUser cmdlet (which will result in a loss of contacts)
Dave Stork goes on to describe some issues with a combination of the UCS, Lync on-premises and Exchange Online (and these appeared to apply to my Lync 2013/Skype for Business Online hybrid solution too).
Microsoft knowledge base article 2614614 has lots more information on integrating Exchange Online with Skype for Business Online, Lync Server 2013, or a Lync Server 2013 hybrid deployment
In my post last week about Office 365 and proxy servers, I mentioned issues with Outlook autodiscover. These were not exactly easy to troubleshoot, often with multiple subject matter experts looking from different angles (network, client applications, Exchange, firewalls, etc.). During the process, we used a few tools (as well as examining the traffic hitting the proxy servers) and I thought I’d highlight them here (if only for my own future reference):
Yesterday, I was playing music on Spotify and it kept stopping because someone else was using my account… that’s not an uncommon occurrence as my kids are often using it but I didn’t think they were this time. After the usual squabble over “Play it here”, Nno, play it here”, “No. Play. It. Here.”, I managed to listen to the tracks I wanted to hear.
Then, this morning, I tried to sync some music to my Spotify account, only to find that my iPhone told me Spotify was being used on a complete stranger’s Phone!
One quick password change later and I was sure no-one else was using it. I later removed all devices from my account and re-added them, just for good measure.
Later in the day though, I noticed that all of my playlists were missing. I also saw that my activity stream showed a lot of music that I hadn’t listened to:
Someone else has definitely been using my account. Or at least that’s what Spotify thinks!
I could live with the account activity but missing playlists were a big concern. Luckily, Spotify support pointed me to a link to recover playlists where, sure enough, I saw they had been deleted yesterday! It took a few visits to that link before all of my playlists were located and recovered but I seem to be back to where I was before the mix-up.
Now, I don’t think that Spotify has been compromised – if someone had hijacked my account they would have changed my password and locked me out, surely? But I do suspect a database corruption. Spotify aren’t admitting anything is up, of course… but my trust in the service has been severely damaged.
Writing PowerShell scripts over the last couple of weeks has been a steep curve. I’ve watched PowerShell from afar over the years but don’t really use it enough to say I know it. Luckily, many others do, and they’ve posted their knowledge on the ‘net. This is what I drew upon:
Office 365 and proxy servers don’t mix very well. Well, to be more accurate, thousands of Outlook, Skype for Business and OneDrive for Business clients, each with multiple connections to online services can quickly build up to a lot of (persistent) connections. If you haven’t already, it’s well-worth reading Paul Collinge’s blog post on ensuring your proxy server can scale to handle Office 365 traffic.
Microsoft recommends that the network is configured to allow unauthenticated direct outbound access to a published list of URLs and IP ranges (there’s also an RSS feed) – although I’ve had customers who take issue with this and don’t think it’s a reasonable expectation in the enterprise. My view? You’re adopting cloud services; your network boundary has moved (disappeared?) and the approach you take to managing the connectivity between services needs to change.
Perhaps as more people take advantage of services like ExpressRoute for Office 365, things will change but, for now, every Office 365 implementation I work on seems to involve a degree of proxy bypassing…
Some of the issues I experienced in a recent implementation included:
- OneDrive for business unable to perform an initial synchronisation, but fine on subsequent syncs. It seems that the OneDrive client downloads http://clientconfig.microsoftonline-p.net/fplist.xml when it first syncs. We could get it to work when going through a different proxy server, or direct to the Internet; but the main proxy server had to have a list of trusted sites added. The managed services provider had previously allowed access to some known IP addresses (a risky strategy as they change so frequently and the use of content delivery networks means they are not always under Microsoft’s control), but the proxy server had the capability to trust a list of target URLs too.
- Outlook unable to reliably redirect after Exchange mailboxes were migrated to Exchange Online. In this case, we found that, even with the trusted URLs in place on the proxy, as part of the Outlook Autodiscover process, Outlook was trying to contact autodiscover-s.outlook.com. The proxy wasn’t allowing unauthenticated access and Outlook didn’t know how to cope with the authentication request. Once autodiscover-s.outlook.com had been added to the proxy server’s unauthenticated access list, Outlook Autodiscover began to work as intended.
- Lync/Skype for Business Online calls working internally, but not with external parties. Users dropping off the call after a few seconds. We still haven’t got to the bottom of this, but strongly suspect the network configuration…
- Exchange Hybrid free/busy information not available cross-premises. Again, this seems to be related to the Exchange servers’ ability to see the Internet (free/busy lookups are performed by the server, not the client).
This time last year, Office 365 gained an App Launcher as part of a new navigation experience for Office 365 on the web. Users can add and remove tiles from this launcher – and administrators can provide new tiles to point to corporate resources – for example a CRM platform or the company intranet.
Unfortunately, not all customers want their users to use all of the features and functionality in Office 365 and the administrative controls to manage the App Launcher for all users are limited. I’d argue that part of consuming a cloud service is adapting to new features and functionality as they are released but that doesn’t go down well with everyone, often leaving me trying to find ways to disable or hide parts of the service. The following settings may help to selectively remove tiles from the Office 365 App Launcher but It’s not always straightforward – and it’s also subject to change (with a new admin center on the way):
- Admin: revoke a user’s administrative rights.
- Instant messaging and web conferencing: remove the Skype for Business Online licence and this functionality will disappear (there is no associated tile).
- Mail, Calendar, People, Tasks: remove the Exchange Online licence and these tiles will go too.
- OneDrive for Business, Sites, Office Web Apps: remove the SharePoint Online licence (which also requires that you remove the Office Online licence).
- Office 365 Store: a switch was recently added to disable this tile, under Service Settings, User Purchasing, Display Office 365 App Store Tile.
- OneDrive for Business: hide in the SharePoint Admin Center settings, under show or hide options.
- Office 365 groups: Using PowerShell against Exchange Online, edit the Outlook Web Access policy with
Set-OwaMailboxPolicy -GroupCreationEnabled $False -Identity PolicyName. If you only want to apply the change to a subset of users, create a new policy and apply it accordingly.
- Sites: hide in the SharePoint Admin Center settings, under show or hide options.
- Delve: turn off the Office Graph in the SharePoint Admin Center settings. Delve will still be there in parts though: for example when users access their profile.
- Sway: turn off under Service Settings, Sway, Let people in your organization use Sway. Unfortunately it won’t remove the tile.
- Video: in the SharePoint Admin Center settings, under Streaming Video Service, disable streaming video through Azure Media Services and disable the Video Portal.
- Yammer: for this one you’re between a rock and a hard place: Yammer Basic is anarchic; Convert to Yammer Enterprise and the tile will be visible to users – you cannot turn it off.
Some of these options merely hide capabilities – they may not be entirely disabled – and my recommendation would always be to leave settings enabled and teach users how to make use of the platform. In particular, turning off the Office Graph may have wider reaching implications.
Meet the Office 365 App Launcher
For the last few months, I’ve been getting more and more infuriated with my PowerShell sessions opening in a tiny raster font (4×6). On a high resolution display like the one on the Surface Pro 3, that’s a complete pain and, whilst I could change the font in the properties for that session, it wasn’t “sticky”, with an error that said:
Error Updating Shortcut
Unable to modify the shortcut: Check to make sure it has not been deleted or renamed.
For reference, I’m experiencing this on Windows 8.1, 64-bit and it only applies to the Windows PowerShell shortcut and the Microsoft Azure PowerShell shortcut – not to the PowerShell ISE, nor to the various shortcuts created by modules like the SharePoint Online Management Shell, Lync Server Management Shell or the Windows Azure Active Directory Module for Windows PowerShell.
Solving the “stickiness” of my changes was simple enough – I asked our support team to change the permissions on the shortcut to allow Users to Modify it – but I still couldn’t get it to stay on my preferred setting: Lucida Console 20.
I could set it to Consolas, or raster fonts (urgh), but Lucida Console just wouldn’t stick. It’s been recorded as a bug in Microsoft Connect for a couple of years but there’s no sign of a fix yet (not even in Windows 10).
Being unable to set the default PowerShell font to Lucida Console seems to be a widely recognised problem. Various options are discussed on this SuperUser post including that it may be a language issue. Others have suggested the issue is the space in the font name, with a workaround that involves installing a new font and editing the registry (not an option for me without administrator permissions). I also looked at using the SetConsoleFont module to change the font within my PowerShell profile but struggled to work out the settings I would require.
In the end, I gave up and accepted that Consolas 24 is vastly preferable to a 4×6 raster font!
For a long time now, the default behaviour in OneDrive for Business has been to provide a folder (called “Shared with Everyone”) which is an easy way to share files with everyone in the organisation. By default, the permissions on this allow editing of files in the folder by “Everyone except external users” (and guest links can be provided for others – either on a view-only or an edit basis).
From 1 August 2015, Microsoft changed the default setting for OneDrive for Business so that the Shared with Everyone folder is no longer provisioned. It can be created manually by a user, or the tenant settings for the entire organisation can be set to provision the folder by default:
Set-SPOTenant –SharingCapability Disabled –ProvisionSharedWithEveryoneFolder $true
It’s also possible to remove users’ ability to use the “Everyone,” “All Users” and “Everyone except external users” groups from the people picker in OneDrive for Business and SharePoint Online with the following commands:
Set-SPOTenant -ShowEveryoneClaim $false
Set-SPOTenant -ShowEveryoneExceptExternalUsersClaim $false
Set-SPOTenant -ShowAllUsersClaim $false
Enabling them is achieved with the equivalent commands but set to